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);
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.
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:
Check out my own question about this very same thing. in the end though, all you need is something like this:
Why is my WPF textbox "kinda" readonly?
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 theWM_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):