To close the window I call (inside the DLL)

DestroyWindow(hWnd);

Then when WM_DESTROY arrives in the message queue:

PostQuitMessage(0);

Unfortunately the call to PostQuitMessage has no effect, WM_QUIT msg never arrives and the thread doesn't stop. I have an example program which uses the DLL and the only way I can get it to close properly is to call PostQuitMessage from inside the program itself.

I can fix the problem roughly by using my own boolean flag in the message loop, ie.
while (!m_bQuit) {
if (PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE))
...
TranslateMessage(&msg);
DispatchMessage(&msg);
...
}
...but I would really like to know why PostQuitMessage can't be called from inside the DLL.

I hope this all makes sense to someone Cheers.

------------------

[This message has been edited by rowanseymour (edited June 05, 2001).]

Try doing a PostMessage(hWnd, WM_QUIT, 0,0) explicitly rather than using PostQuitMessage. If this works great, if it doesn't, oh well.

Another thing to try is to ensure that both your dll and main program share memory heaps. For some reason, that might be stuffing things around. Not sure why, but it is a possiblity.

Also, if you want, you can send the code for the message loop and enough to test it out, and I can try a few things to see if I can hunt it down.

Phil

Found this on MSDN

The following concerns arise when a function in a DLL retrieves messages by calling GetMessage or PeekMessage:

When the DLL function retrieves, translates, and dispatches messages, the calling application and the DLL function may be re- entered. This is because message retrieval can cause the calling application to respond to user input while waiting for the DLL function to return. The DLL function can return a reentrancy error code if this happens. To prevent reentrancy, disable windows and menu-items, or use a filter in the GetMessage or PeekMessage call to retrieve specific messages.

The application can terminate while execution is in the DLL function's message retrieval loop. The WM_QUIT message retrieved by the DLL must be re-posted and the DLL function must return to the calling application. This allows the calling application's message retrieval loop to retrieve WM_QUIT and terminate.

When the DLL retrieves messages, it must allow the calling application to preprocess the messages (to call TranslateAccelerator, IsDialogMessage, and so forth) if required. This is be done by using CallMsgFilter to call any WH_MSGFILTER hook that the application may have installed.

I think I'll just stick my current WM_QUIT workaround. Keep things simple .

------------------