locked
Issue with setting focus within a WPF UserControl hosted within an ElementHost in a WindowsForms child MDI form RRS feed

  • Question

  • I seem to having an issue with setting focus within a WPF UserControl hosted within an ElementHost in a WindowsForms child MDI form.

    I've been able to reproduce this with a very simplistic case where I set up an Windows Forms MDI environment and then use a Form control set as an MDI child which hosts a WPF User Control which only contains two TextBox elements. If I open the child Form as an MDI child by setting its MdiParent property to my MDI parent Form the first TextBox is not focused however if I Show() the same child Form without setting the MdiParent property then the Form shows with the expected focus set to the first WPF TextBox element set.

    Can somebody explain why we have a difference in focusing behavior when opening a Form containing WPF within an ElementHost as an MDI child versus a regular dialog window? Is there any way workarounds or do I have have to consider other pure WPF based MDI solutions such as Actipro?
    Thursday, March 26, 2009 2:38 AM

Answers

  • So far the official word from Microsoft is the issue I've described above is an acknowledged bug but will not be fixed for .NET 3.5. Also this issue won't be fixed in the next version the .NET Framework (.NET 4.0).

    For now I'm thinking I have two paths to pursue:
    1. Attempt to find any workaround to shift focus to my hosted WPF control through code. Unfortunately I've tried several things and have had no luck thus far.
    2. Start looking at pure WPF MDI solutions such as the one offered by Actipro. It looks like many of the third party control libraries for this are centered mostly around docking but also seem to allow some MDI-like functionality as well.

    If anybody can help me narrow down either of these paths I would greatly appreciate it and I'll make sure to keep this topic updated as I make any progress with this issue.
    • Marked as answer by kainhart Wednesday, June 17, 2009 7:05 PM
    • Edited by kainhart Wednesday, April 7, 2010 10:20 PM
    Monday, March 30, 2009 10:08 PM

All replies

  • By the way, if you take WPF and the Element out of the equation and use pure Windows Forms it appears that focus is all good in both the MDI and non MDI child form scenarios.
    Thursday, March 26, 2009 2:39 AM
  • I went ahead and added a bug report for this behavior for .NET Framework 3.5 SP1 on the Microsoft Feedback Center. I guess we can see what the official response is while we try to discover a workaround for the time being.

    Cannot set focus within a WPF UserControl hosted within an ElementHost in a WindowsForms child MDI Form
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=426904
    Thursday, March 26, 2009 3:01 AM
  • So far the official word from Microsoft is the issue I've described above is an acknowledged bug but will not be fixed for .NET 3.5. Also this issue won't be fixed in the next version the .NET Framework (.NET 4.0).

    For now I'm thinking I have two paths to pursue:
    1. Attempt to find any workaround to shift focus to my hosted WPF control through code. Unfortunately I've tried several things and have had no luck thus far.
    2. Start looking at pure WPF MDI solutions such as the one offered by Actipro. It looks like many of the third party control libraries for this are centered mostly around docking but also seem to allow some MDI-like functionality as well.

    If anybody can help me narrow down either of these paths I would greatly appreciate it and I'll make sure to keep this topic updated as I make any progress with this issue.
    • Marked as answer by kainhart Wednesday, June 17, 2009 7:05 PM
    • Edited by kainhart Wednesday, April 7, 2010 10:20 PM
    Monday, March 30, 2009 10:08 PM
  • I can think of two ways of faking the keyboard events, but they will not be sent to the element you want, unless there is some way to invoke the event that I am not aware of.
    1. You can subscribe to the global keyboard events of the operating system, using unmanaged code, and only respond to them if you have the correct focus.
    2. You can create a timer that invokes an handler that stores the state of every key and determines if any of the keys have changed since the last time around, using the System.Windows.Input.Keyboard.IsKeyDown method.  This one may be a little more processor intensive, but it does not require any unmanaged code.
    I don't know if these would help anyone, but that is as close as I could come up with.
    Thursday, August 6, 2009 8:56 PM