Our application uses a ribbon & docking/MDI with floating document windows, so I have followed the advice from http://blogs.msdn.com/b/visualstudio/archive/2010/03/09/wpf-in-visual-studio-2010-part-3-focus-and-activation.aspxto prevent the ribbon taking focus away from the floating window. I have added the lines to set DefaultAcquireHwndFocusInMenuMode/DefaultRestoreFocusMode in the app's static ctor, and modified our commands to use CompositeCommand/IActiveAware from Prism to route to the right document.
This all works great when the document contains WPF content, but our application has a lot of legacy MFC/Win32 components that are interoped in. I discovered a problem were after clicking on a ribbon button all keyboard input to Win32 controls would stop working. I eventually tracked this down to a InputManager.PushMenuMode call that was missing a corresponding PopMenuMode call, leaving menu mode enabled which causes HwndSource to eat all WM_KEY messages before dispatching them.
It seems that when focus moves from WPF to Win32, the WPF element will recieve a LostKeyboardFocus event without a corresponding PreviewLostKeyboardFocus. As the ribbon calls PopMenuMode in the Preview event, this gets missed. The guidance from MS on when to call PopMenuMode isn't clear - the blog I linked mentions LostKeyboardFocus in the text, but the example code uses PreviewLostKeyboardFocus with an event handler name that suggests the non-Preview event. I've done some experiments with a standard WPF toolbar instead of a ribbon using LostKeyboardFocus and this appears to fix the problem, and I can't see any obvious other problem from using this event.
Would it be possible to get this changed? Maybe it would be OK to call PopMenuMode from both events, only doing so from LostKeyboardFocus if the Preview event is not seen first.
I have also found a couple of less important problems in this area
- When WPF keyboard focus is in a WPF control such as a TextBox, accessing the ribbon using the keyboard (e.g. Alt, H, V to select Paste) sets focus back to the main window instead of the TextBox, meaning the command is sent to the wrong control
- When a floating DocumentWindow is the active window, it is not possible to access the ribbon using the keyboard (Alt key does nothing)