Our application uses the NetAdvantage WPF controls extensively. The main window has a ribbon with buttons, and then a DockManager/DocumentContentHost that contain multiple ContentPane documents.
When clicking a button on the Ribbon, we want to invoke certain actions on the currently active ContentPane. We do this by parsing through dockManager.GetPanes() and finding the ContentPane with the IsActivePane currently true, so we can find the last active ContentPane and do the required action on it.
This works fine when all the ContentPanes are within tabs or are docked . However when a ContentPane is floating, and when a button is clicked on the Ribbon, focus goes back to one of the tabs on the Main Window. Hence in code, the newly focussed tab is the one acted on, instead of the floating ContentPane that was meant to be acted on.
This behavior is different from that of Visual Studio 2008. If you float a window within VS, you can click on any of the buttons or menu options on the Main Window within VS, but focus stays on the floating window. You can try this by using any floating window within VS and the Undo toolbar button within the main window.
Could you please let me know how I can get a button on a Ribbon to work with a floating ContentPane without focus changing back to the Main Window?
Thanks in advance.
Currently there is no way to prevent this. The floating windows are in two different WPF windows and in WPF when you click on a menu/toolbar button/etc. it will take keyboard focus which will activate that window. In VS, you will notice that the keyboard focus is still in the floating window and VS just intercepts the key messages to route them to the menu.
Is there any news on this? I have contextual tabs for each content pane, and when the content pane is floating, i can never get to its contextual tab.
Joseph,
I am trying to solve the very same issue. Can you provide more detail (even a sample) of what you did?
Thanks
Murray
Ben,
Great solution, thanks for sharing that!
Joe
Thanks for the answer. We couldn't do that here, so instead I hooked into the WndProc via an HwndSource for our WPF application, and swallow WM_SETFOCUS when the mouse is over the ribbon. This seems to work with no negative side effects (though I say that with only a couple of hours of testing on the solution).
In our case, as a workaround for this limitation, we ended up just disabling the floating property (.AllowFloatingOnly = false).