Winetest progress bar

Shachar Shemesh wine-devel at
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.


Shachar Shemesh
Lingnu Open Systems Consulting

More information about the wine-devel mailing list