If a usercontrol which contains ultratoolbarsmanager is hosted inside WPF WindowsFormsHost, shortcut keys on ultratoolbar tools are not working. Is this a known issue and is there any workaround?
Any help would be appriciated,
thanks,
Jurica
I believe the normal message filters will not work if you are not in a Windows Forms application. Try to call Infragistics.Win.Utilities.ForceNativeMessageFilter() before your main window is created. This usually fixes a lot of these issues when the UltraToolbarsManager is on unmanaged windows and should also fix your issue.
I am experiencing this issue as well. I tried that call you mention before my first WinForms window is started, but no luck. I also tried it right before the WPF window is started as well, also with no luck.
Any other ideas?
I just tried this and you are correct. It looks like my answer was not complete. You need to force the native message filter, but you also need to create a derived UltraToolbarsManager. There is a thread where this was discussed and I posted a starting point for the derived manager which should help you. Here is the post where I provide the derived manager: http://community.infragistics.com/forums/p/3349/25277.aspx#25277
I just went and tried a derived implementation like you suggest in that other thread but this doesn't seem to solve the problem.
Could this be because I've simply used your default implementation of FormWindowState?
To be honest, I'm not sure what I would have to implement here.
I used this in conjunction with the call to Infragistics.Win.Utilities.ForceNativeMessageFilter();
Looks like the implementation of IsControlOnActiveForm in your example walks up the window heirarchy until it reaches the first child of the active form, but then the call to NativeWindowMethods.GetParent returns IntPtr.Zero for that form, rather than the hwnd of the parent Window.
In this case, the parent window is the WPF window (though I believe there is more in that hwnd heirarchy that is WPF which is being walked correctly.
Spy++ does correctly show the parent window for the, so not sure why that final GetParent() call is not working from c#.
I gotta head off, but i'll keep going with this tomorrow and let you know if I figure out whats going on.
Ah. I wonder why I commented that line out. I haven't realised I had done that. Adding it back in does work for me.
However for some reason in our main app it does not work. This is not a problem though, we have the workaround (to create a window as in the sample and immediately close it before we start loading the main parts of our UI).
I narrowed it down to a single form in our app which caused the WPF/UTM window not work correctly. That form had an UTM which made me think that was the problem. It's possible it's something else on that form. I will spend a bit of time next week trying to see exactly what's on that form that might be causing the problem. (it doesn't use a messagefilter itself)
I can not reproduce the issue with the sample you attached. Here are the steps I followed:
And the message box appeared. Do these steps not show the message box for you? Or am I trying to reproduce the wrong thing?
Ok i've finally got to the root cause, and attached a modified version of your sample that demonstrates the problem.
Shortcuts in the WPF window do not work if you create an instance of a standard UltraToolbarsManager (UTM) on a windows form before you create a derived version on a Winforms user control (with derived UTM) on a WPF window.
In our case, our main app is WinForms, but for some bits we are starting to pull in WPF. This particular WPF window with the winforms user control containing the derived UTM is created via a main menu item, so the main app has been running and showing various other things, including windows that contain standard UTMs.
If you create an instance of a derived UTM at any point before creating your first standard UTM, all derived ones will work for the lifetime of the app, regardless of whether they are created before or after the first standard UTM.
It sounds like something else in your application is handling the shortcut keys and not doing anything with them. I'm not sure of a good way to track that down, but Spy++ might help. It will at least direct you to the window handle which is receiving the shortcut keys. That will help you eliminate a lot of your windows and just focus on the one getting the messages.
Your sample works fine when I run it.
If I pull your sample window and controls into our app and spawn the window from there, it doesn't work. We have multi app domains, so to eliminate that avenue I added a secondary app domain to your sample and it all worked ok.
Our app is primarily a Windows forms app as well, which just happens to have some bits of WPF hosted, so I emulated this with a new sample app (ie, new Windows Forms App), created a Winforms Form, make it kick off the WPF Window from your sample app.
This worked fine as well.
It must be something we are doing elsewhere in our app that is causing the key strokes to go missing. This quite a large SCSF app thats using the SCSFContrib project to add WPF support, so it's possible that something somewhere (such as workspaces or CAB infrastructure) is just getting in the way.
Thanks for your help anyway - Hopefully at least you've managed to get a pre-canned sample up onto the forums for the next straggler who comes by :)
Cheers,
Mark