No Keyboard Input in WindowsFormsHost after Interacting with Ribbon TextBox or ComboBox

Hi Nate,

I'm sorry you're running into trouble.  I haven't heard of anything like that but WPF/WinForms interop focus can sometimes be wonky.  Can you make a new simple sample project showing this happening so we can debug it and send that over to our support address, referencing this thread?  Please exclude the bin/obj folders from the ZIP and rename the .zip file extension so it doesn't get spam blocked.  Thanks!

Thanks for the response. As I was building my test app to send in I discovered I'd set 

HwndSource.DefaultAcquireHwndFocusInMenuMode = false;

in my App.xaml.cs. This appears to be what was messing up my keyboard focus for legacy windows in WindowsFormsHost after interacting with the Actipro Ribbon controls. Once I removed that line, keystrokes started flowing again and all is well.

Thanks again for your help and the great components. We're about to ship our brand new, clean. modern UI featuring your Ribbons and Docking and response during beta testing has been very positive. I really appreciate it!

Hi Nathan,

Great, I'm glad you sorted it out and thanks for the comments.  Good luck with your app deployment in the next few days!  And feel free to post a link to some screenshots of it.  We love to see what our customers create with our controls.

Hi,

We are currently experiencing the same problem within a similar scenario. (Version is 17.2.0665)

InputManager.IsInMenuMode stays true if I click first in a popup button (or a combobox) within a ribbon and then on an other button within the ribbon.

This only occurs if HwndSource.DefaultAcquireHwndFocusInMenuMode=false, but we need it in combination with Keyboard.DefaultRestoreFocusMode=RestoreFocusMode.None, as explained here. Hence it is not an option for us to set DefaultAcquireHwndFocusInMenuMode to true.

App.xaml.cs:

public App() {
    HwndSource.DefaultAcquireHwndFocusInMenuMode = false;
    Keyboard.DefaultRestoreFocusMode = RestoreFocusMode.None;
}

 MainWindow.xaml:

        <ribbon:Ribbon DockPanel.Dock="Top">
            <ribbon:Ribbon.Tabs>
                <ribbon:Tab Label="Tab 1">
                    <ribbon:Group Label="Group">
                        <ribbon:StackPanel>
                            <ribbon:PopupButton Label="1. Click here" ImageSourceLarge="{StaticResource MyIcon32}">
                                <StackPanel>
                                </StackPanel>
                            </ribbon:PopupButton>
                            <ribbon:Button Label="2. Then click here" ImageSourceLarge="{StaticResource MyIcon32}"/>
                        </ribbon:StackPanel>
                    </ribbon:Group>
                </ribbon:Tab>
            </ribbon:Ribbon.Tabs>
        </ribbon:Ribbon>

        <docking:DockSite>
            <docking:Workspace>
                <docking:TabbedMdiHost>
                    <docking:TabbedMdiContainer>
                        <docking:DocumentWindow Title="MyDocument">
                            <WindowsFormsHost docking:InteropFocusTracking.IsEnabled="True">
                                <WindowsFormsHost.Child>
                                    <wf:TextBox Multiline="True" WordWrap="True" AcceptsReturn="True">
                                        <wf:TextBox.Text>
                                           3. Result: InputManager.Current.IsInMenuMode stays 'true'. WinForms-Controls like this textbox do no longer get any keyboard input.
                                        </wf:TextBox.Text>
                                    </wf:TextBox>
                                </WindowsFormsHost.Child>
                            </WindowsFormsHost>
                        </docking:DocumentWindow>
                    </docking:TabbedMdiContainer>
                </docking:TabbedMdiHost>
            </docking:Workspace>
        </docking:DockSite>

I can also provide a complete sample project if that helps.

Could you have a look at this? Thank you!

Stefan

Hi Stefan,

Thanks for letting us know about this scenario.  I believe we were able to track down the problem and have fixed it for the next build 673.