Question

I have a WinForms Form that used to be a standalone application, but is now being started as part of a larger WPF app. It is still a separate window, not contained within a WPF window. The problem I’m seeing is that the ProcessCmdKey event in the window never fires anymore, so I’m having problems handling special command keys. This used to work fine and the shortcut handling code is unchanged from earlier.

The root of the problem seems to be that the form is no longer being inited from the WinForms Application.Run method, and so it no longer has its own message loop. Is there any way to fix this while still having the WPF and WinForms windows share an UI thread, or will I have to set up a separate thread for the WinForms window for this to work? I’d like to avoid it if possible as I then have to set up cross-thread communication for all the things that are now done by simple method calls.

Answer 1

Your guess is accurate, ProcessCmdKey() is directly called from the Winforms message loop as started by Application.Run(). You are now running the WPF message loop, it doesn’t know anything about the Winforms keyboard handling. Tabbing should be dysfunctional too.

There is no clean fix for this, the object models are too different. System.Windows.Forms.Integration provides interop between the two but that works at the control level, not the window level. Form.ShowDialog() is a possible workaround.

And yes, you can start a new STA thread (use Thread.SetApartmentState) and call Application.Run() to start a Winforms message loop. A nasty problem with that however is that these forms have no Z-order relationship with the WPF windows. They’ll easily disappear behind the window of another app. Fixing that requires pinvoking SetParent(), the Owner property will throw an exception.