DocumentWindow loses its active state with WinForms hosted content

Posted 3 months ago by Avatar Dmitry B.

Dear Actipro team,

we have discovered another focus issue when using some hosted WinForms user controls as the DocumentWindow's content.

The issue can be reproduced with a simple setup:

    <docking:DockSite UseHostedPopups="False" IsLiveSplittingEnabled="False">
              <docking:DocumentWindow Title="Interop WinForms+WPF">
                <WindowsFormsHost docking:InteropFocusTracking.IsEnabled="True">

Note that we're using the InteropFocusTracking.IsEnabled attached property as suggested in the documentation.

The NestedUserControl is a  simple WinForms user control:

  public partial class NestedUserControl : UserControl
    public NestedUserControl()
      elementHost1.Child = new WpfUserControl();

 It contains some native WinForms controls and an ElementHost that holds a WPF user control:

<UserControl x:Class="ActiproInterop.WpfUserControl"
    <StackPanel Orientation="Vertical">
            <TextBox Margin="16" Text="Hosted WPF Control"/>

So we have a nested setup in this case: DocumentWindow (WPF) -> UserControl (WinForms) - > UserControl (WPF).

This setup works well (despite of two levels nesting), but we have a problem that the DocumentWindow's title bar (tab header) becomes inactive (selected but not focused) on mouse clicks inside the nested WPF user control. Sometimes it gets active back, but then resets to inactive again. Just some clicks on the WinForms and nested WPF controls - you'll see that.


Could you please check whether it's possible to improve the InteropFocusTracking in that way so it works for a nested setup that we have?

Comments (3)

Posted 3 months ago by Actipro Software Support - Cleveland, OH, USA

Hi Dmitry,

I'm not sure a layout like that will work in terms of focus tracking.  It's hard enough to get WindowsFormsHost's WinForms content to report focus up since it doesn't natively happen in WPF without the numerous workarounds we've added in the InteropFocusTracking extension.  Our workarounds handle most WinForms controls scenarios.

But when you add another layer of WPF within that, my guess is that the nested WPF content there might be on an "island" and not pass any sort of focus events up to/past the WinForms content boundary.  And our InteropFocusTracking workarounds only work for interop (Win32 controls like WinForms).  They won't likely be able to do anything for a WPF island within that interop.

If you'd like us to take a look, please make a new very simple sample project that shows the issue and send that to our support address.  Exclude the bin/obj folders from the ZIP you send and rename the .zip file extension so it doesn't get spam blocked.  Then we can at least take a peek and see if there's anything we can do.  But knowing how bad WPF's handling of focus reporting is over interop boundaries, I'm not optimistic for this particular scenario. 

For best results, I would suggest you change your design to either exclude this nested WPF content, or eliminate the WinForms portion of the content in the middle.

Actipro Software Support
Posted 3 months ago by Dmitry B.

Dear Actipro support,

thank you for your quick reply!

Of course we would be glad to change our design so that it doesn't have that two level nesting. But currently this is not possible due to lots of legacy components we need to maintain.

I prepared a simple repro solution and sent it to your support address today. Please let me know if you need some additional information!

Posted 3 months ago by Actipro Software Support - Cleveland, OH, USA

Hi Dmitry,

Thanks for the sample.  I'm glad we were able to find a solution for this problem.  The update will be in build 665.

Actipro Software Support
Information The latest build of this product (2018.1 build 0670) was released 10 days ago, which was after the last post in this thread.

Add a Comment

Please log in to a validated account to post comments.