WPF TextBox not accepting Input when in ElementHost in Window Forms

Question

We are developing a UI Control in WPF to be consumed within an existing Windows Forms / MFC application engine (Rhino 3D).

The application engine exposes the ability create a "Dockbar" which essentially lets you put Windows Forms controls inside a child window which can dock to the Engines Interface.

I am attempting to put a simple WPF TextBox inside an ElementHost control, which is added to the Dockbar. This appears to work fine at first glance; but after attempting to type into the TextBox only certain sequences actually show up in the TextBox. The DELETE, BACKSPACE, COPY, PASTE, and SELECTING TEXT work. If you type A-Z, 1-9, etc. those keys do not show up.

I have SCOURED the net, and have heard about the ElementHost.EnableModelessKeyboardInterop() but this only applies to WPF Windows being created from the form. I am only creating WPF UserControls and hosting them in the ElementHost control.

I saw a post which talked about the Dispatcher.Run(), and it sort of works but breaks the rest of the form:

System.Windows.Threading.Dispatcher.Run();

The PreviewKeyUp, PreviewKeyDown, KeyUp, and KeyDown events all fire on the TextBox, but alas no text shows up in the TextBox.

I don't know much about Windows Messages, but using WinSpector I noticed that no WM_GETTEXT messages were coming from the TextBox (if they even should be I don't know).

I also create a new Windows Forms project and did the same thing in there and it works fine, so it must be an issue with how the windows are created and docked within the Rhino 3D engine.

Here is the sample code which doesn't work:

ElementHost el = new ElementHost();
System.Windows.Controls.TextBox t = new System.Windows.Controls.TextBox();
t.Width = 100;
t.Text = "TEST";
el.Child = t;
panel1.Controls.Add(el);

Optometry

Answer 1

I finally figured it out after 2 days of head scatching...

The MFC Dialog window was taking the WM_CHAR messages and preventing the control from handling the input. So in order to prevent this, I hook the HwndSource and whenever I receive the WM_GETDLGCODE message I respond back with the types of input to accept, and then mark the event as handled.

I created my own TextBox in order to prevent having to fix every textbox (see Below):

    /// <summary>
    /// Interop Enabled TextBox : This TextBox will properly handle WM_GETDLGCODE Messages allowing Key Input
    /// </summary>
    class IOTextBox : TextBox
    {
        private const UInt32 DLGC_WANTARROWS = 0x0001;
        private const UInt32 DLGC_WANTTAB = 0x0002;
        private const UInt32 DLGC_WANTALLKEYS = 0x0004;
        private const UInt32 DLGC_HASSETSEL = 0x0008;
        private const UInt32 DLGC_WANTCHARS = 0x0080;
        private const UInt32 WM_GETDLGCODE = 0x0087;

        public IOTextBox() : base()
        {
            Loaded += delegate
                          {
                              HwndSource s = HwndSource.FromVisual(this) as HwndSource;
                              if (s != null)
                                  s.AddHook(new HwndSourceHook(ChildHwndSourceHook));
                          };
        }

        IntPtr ChildHwndSourceHook(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
        {
            if (msg == WM_GETDLGCODE)
            {
                handled = true;
                return new IntPtr(DLGC_WANTCHARS | DLGC_WANTARROWS | DLGC_HASSETSEL);
            }
            return IntPtr.Zero;
        }
    }

Optometry

Thanks, this was exactly what I needed. I put it in the UserControl, like IvanH suggested below. Works like a charm! – Aeriform

Thanks! This came up as a problem for us today, and this quickly resolved it! – Soupy

I have tried this and cannot get it working, have a WPF window running via an excel add-in. The data is still going into the excel worksheet. – Goodsell

Answer 2

Check out my own question about this very same thing. in the end though, all you need is something like this:

Window window1 = new Window();
ElementHost.EnableModelessKeyboardInterop(window1);
window1.Show();

Why is my WPF textbox "kinda" readonly?

Titanothere

Actually in my question I stated that your solution doesn't apply, I am not a window, I am a UserControl inside an ElementHost, inside of an MFC Dialog Window... – Optometry

Your right, my bad. I deserved that for not paying close attention. – Titanothere

@Titanothere This answer helped me greatly!!! I have spent weeks trying to solve this issue. Thank you!!! – Ruwenzori

@Ruwenzori happy to have been a help! I know how hard it is sometimes to even ask the question in useful way; and have spent days looking for something simple. – Titanothere

Answer 3

I have a similar issue with a wxWidgets parent window and embedded WPF TextBox controls. I found that although attaching ChildHwndSourceHook does solve the problem of not receiving keyboard input, I ended up with occasional duplicate space characters. It seems the WM_KEYDOWN message handles the space characters reliably, but a duplicate WM_CHAR message is also received for some of the spaces. To solve this I added the following clause to the body of the ChildHwndSourceHook function, which simply ignores the WM_CHAR space character:

        const UInt32 WM_CHAR = 0x0102;

        if (msg == WM_CHAR)
        {
            // avoid duplicated spaces when parent window is a native window
            if (wParam.ToInt32() == 32)
                handled = true;
        }

Cinerary

Man, you saved my life, after 1 day of debugging...I have similar issue with enter key, sometimes was sent twice. WM_KEYDOWN - WM_CHAR - WM_KEYUP, this was the order. "Eating" the WM_CHAR for Enter looks does not cause any problem except fixing the doubling issue. – Marvelmarvella

Answer 4

It is not necessary to create derived TextBox. The code for IOTextBox can be used in a UserControl hosting textboxes. I have successfully tested it with WPF control used for custom options page used in VS2010 package.

Eumenides

Could you please explain how to use Iotextbox? – Loring

@RajeshSubramanian: I is a bit difficult to answer this after 6 years but I make an attempt. The whole question is about rather specific issue with TextBoxes used in a ElementHost control. The IOTextBox in the Jason Stevenson answer is a derived TextBox for resolving the issue. My answer says that is not necessary to create a derived control and it is possible to handle the event in a control container (more lightweight but less encapsulated). – Eumenides

Thanks a lot. I am facing the same issue. I wanted to know if there is any simple solution exists. – Loring