Winetest progress bar
wine-devel at shemesh.biz
Sat Jan 3 08:04:19 CST 2004
Mike Hearn wrote:
>On Sat, 2004-01-03 at 09:29, Dimitrie O. Paun wrote:
>>>1. 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
>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
It's main window being closed with WM_DESTROY (usually by calling
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.
Lingnu Open Systems Consulting
More information about the wine-devel