[Bug 1918] PostMessage(hwnd,WM_CLOSE,0,0)

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=1918





------- Additional Comments From jbj at image.dk  2005-11-10 00:06 -------
There is a misunderstanding in Mike Hearns comment #4 (from 2004-01-02).  The
way this is supposed to work (in all known windows versions, even 16 bit) is:

1. PostMessage places WM_CLOSE in the queue, no special treatment

2. GetMessage/DispatchMessage passes WM_CLOSE to the WindowProc, no special
treatment.

3. The WindowProc in the App does whatever it pleases, including deciding if it
wants to call DefWindowProc or not.  In the sample this happens to be a call to
DestroyWindow, but anything goes.  If WindowProc had contained code to pass the
message on to DefWindowProc, DefWindowProc would have called DestroyWindow too,
but DefWindowProc is not called in the sample.  There is still no special
treatment. Some applications RELY on the ability to refuse WM_CLOSE by simply
doing nothing.  For instance Notepad will invoke MessageBox (Save Yes/No/Cancel)
and do nothing if the user clicks cancel.

4. DestroyWindow is supposed to SendMessage(WM_DESTROY) as one of its last
actions, causing WindowProc to be invoked recursively to handle that message.
I suspect the original bug was that this did not happen correctly.

5. The samples WindowProc happens to call PostQuitMessage from its WM_DESTROY
case, but if the WindowProc is never called with WM_DESTROY due to a wine bug,
this doesn't happen.

6. If PostQuitMessage was actually called, the WM_QUIT message will end the
message loop once it trickles to the head of the queue.  But if PostQuitMessage
was never called, this obviously won't happen.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.