views:

180

answers:

2

I'm creating a NativeWindow subclass ('MyNativeWindow') in order to use its message pump to communicate with some old DLL. My code runs inside a WinForms application, but I'd like to keep the DLL and it's message processing outside the scope of the GUI.

When creating MyNativeWindow from the application context (just before creating my application's main form), everything works - the NativeWindow's WndProc is called and events are processed. However, when I use a thread to initialize MyNativeWindow it seems the message pump won't run.

Is there any limitation on the creation of NativeWindow?

+1  A: 

I'm not sure what you are expecting to happen here so I'm not sure if I can answer you fully. A NativeWindow does not have a message pump. It simply sub-classes an existing window by replacing its window procedure. When the thread's message pump delivers a message for that window it goes to the NativeWindow sub-class window procedure not the original window procedure. If the sub-class does not handle it, it should be forwarded to the original window procedure.

I suspect that you are creating the window and then the NativeWindow sub-class on your secondary thread but you are not creating a message pump on that thread. So no messages are ever processed. If you wish to create a message pump on the secondary thread, and keep it from simply exiting, you must create the window and then call some form of Application.Run on that thread. You can then sub-class the window and receive the messages.

Stephen Martin
+1 for a Window has no MessagePump.
Henk Holterman
A: 

You need to start the message pump too, creating a NativeWindow doesn't do that AFAIK.

Shameless plug: try backgrounder, and do something like:

BackgroundHelper helper = new BackgroundHelper();
helper.Background(() => {
    MyNativeWindow receiver = new MyNativeWindow();
});

And see if that works out of the box.

(If not, feel free to pester me in the issue tracker :-).)

rosenfield