Mike Hearn wrote:
On Sat, 2004-01-03 at 09:29, Dimitrie O. Paun wrote:
- If compiled with Winelib, the dialog stays on screen
after the main thread finishes with the tests; under Windows, it disappears at once.
This is a bug in Wine, don't worry about it for now. Having a Winelib version is important so that others that don't have Windows can contribute, and while this is a little annoying, it's no showstopper. Of course, we should eventually fix this...
I think we're tracking this in bugzilla - I was poking at it the other day:
http://bugs.winehq.com/show_bug.cgi?id=1918
Basically it's not at all obvious from MSDN how WM_QUIT is generated from a window being destroyed. I rather suspect that Microsofts defwndproc notices when the window being destroyed is the last one owned by the thread and then does a PostQuitMessage (which we do not). That behaviour should be verified by test case first though.
When you click the close button, a message (I'm not sure which - possibly WM_CLOSE) is sent to the window. DefWndProc takes that message and asks to close the window. This, in turn, sends WM_DESTROY to the window. That's all that happens in Windows. If you want your application to quit at that stage, you have to manually trap WM_DESTROY and call PostQuitMessage. I found that out the hard way.
As a bare minimum, each and every application must handle the following event: It's main window being closed with WM_DESTROY (usually by calling PostQuitMessage). The window session it's in quiting WM_ENDSESSION (the application will NOT receive WM_DESTROY in that case). Paint requests WM_PAIN (no, defwndproc doesn't do beginpaint and endpaint, and if noone else does that, they queue up).
Each and every application must handle all of the above cases, or things go wrong. Not handling WM_DESTROY, for example, causes your app to continue running after all of its windows have closed.
Shachar