PostQuitMessage() not actually posting a quit message?

Started by
16 comments, last by Syrillix 20 years, 3 months ago
This is a strange problem, but its only cropped up in the last day or so, before that it was fine. whenever i make a call to PostQuitMessage() for some reason it doesnt get posted or it gets posted at some obscure time. however if i move the window and then call it (via a key press) it gets posted properly and the app quits? does this sound strange to anyone and more importantly do any windows gurus have any idea why this could be happening? im using your usual message loop with PeekMessage() Translate and dispatch. the message loop checks for a WM_QUIT and exits the loop. every other message is handled in the WinProc. The winproc itself is just calling DefWindowProc() anyway. is windows actually holding off sending the message or is there something else wrong? Get busy livin'' or get busy dyin''... - Shawshank Redemption If a man is talking in the forest, and no woman is around to hear him, is he still wrong? - Unknown Fulcrum
Get busy livin' or get busy dyin'... - Shawshank RedemptionIf a man is talking in the forest, and no woman is around to hear him, is he still wrong? - UnknownFulcrum
Advertisement
It''s hard to tell without any code or anything, but maybe your PostQuitMessage() is what is being called late, rather than the actual posting of the message. Or maybe your app is waiting for something to happen before it does its'' whole PeekMessage() thing.

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

Let''s struggle for our dream of Game!

http://andrewporritt.4t.com
As f8k8 said it''s hard to tell without any code. Where are you calling PostQuitMessage such that it doesn''t seem to be working? I assume it''s from some message in your window procedure, but which one? Post your window procedure (if it''s long just cut out the unnecessary bits).

cheers
sam
I KNOW THE PROBLEM!!!!

I had this too, this SHOULD fix it, put PostQuitMessage(0) under a case called WM_CLOSE as well, it should make the program shut down fine
When General Patton died after World War 2 he went to the gates of Heaven to talk to St. Peter. The first thing he asked is if there were any Marines in heaven. St. Peter told him no, Marines are too rowdy for heaven. He then asked why Patton wanted to know. Patton told him he was sick of the Marines overshadowing the Army because they did more with less and were all hard-core sons of bitches. St. Peter reassured him there were no Marines so Patton went into Heaven. As he was checking out his new home he rounded a corner and saw someone in Marine Dress Blues. He ran back to St. Peter and yelled "You lied to me! There are Marines in heaven!" St. Peter said "Who him? That's just God. He wishes he were a Marine."
WM_CLOSE is sent when the 'X' is clicked. It isn't necessary to handle this message as the default window procedure will do it for you; the default is to call DestroyWindow. DestroyWindow sends the WM_DESTROY message, thus you should make sure that you call PostQuitMessage from WM_DESTROY.

If you need to handle WM_CLOSE yourself (for example, you want to free resources or ask the user if they really want to quit) you should remember to call DestroyWindow yourself.

All you need in your window procedure is something like:

...   case WM_DESTROY:      PostQuitMessage(0);      return 0;   case WM_CLOSE:      if (MessageBox(hwnd, "Are you sure you want to exit?", "Note", MB_YESNO | MB_ICONQUESTION) == IDYES)      {         DestroyWindow(hwnd);      }      return 0;   case WM_KEYDOWN:      if (wParam == VK_ESCAPE)      {         DestroyWindow(hwnd);         return 0;      }      break;... 


and then of course your message loop will terminate when it receives WM_QUIT.

It can be confusing what with all the messages going around, but the above is the "correct" way to do it (by "correct" I mean standard/Microsoft-approved/you shouldn't run into problems if you do it that way). You'll need to call DestroyWindow if you want to exit via some mechanism other than the window 'X' also (see the WM_KEYDOWN label above).

cheers
sam


[edited by - izzo on January 5, 2004 2:24:52 AM]
Show the message pump code too.
Are you getting the message specifically for a window or with NULL for the HWND param (as recommended)?

Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

Make sure you don''t pass a valid hwnd param into GetMessage() or PeekMessage() win32 calls. Set the param to NULL. Other than that everything should go as planned.
Tada, dada, tada, dada... twilight zone:D
ok here goes..
this is the msg pump
MSG msg;while(1){	if( PeekMessage(&msg, m_hWnd,0,0, PM_REMOVE)){                if(msg.messsage == WM_QUIT) break;		TranslateMessage(&msg);		DispatchMessage(&msg);		}        //execute is where PostQuitMessage() is being called-|	Execute();//<----------------------------------------|}


The WinProc is, as i mentioned, in my original post just calling DefWindowProc().
Im calling PostQuitMessage() from Execute which is overridden in the subclass.
It was my understanding that PostQuitMessage() would just post a WM_QUIT message in the message queue and that it would be picked up by the message pump. Ive been using this for years without incident up until last night.
So apart from being not-MS-approved, why else would windows suddenly do this?

at any rate, im using a boolean in the base window class to test for a user quit now. now to find my copy of linux...

Get busy livin'' or get busy dyin''... - Shawshank Redemption
If a man is talking in the forest, and no woman is around to hear him, is he still wrong? - Unknown
Fulcrum
Get busy livin' or get busy dyin'... - Shawshank RedemptionIf a man is talking in the forest, and no woman is around to hear him, is he still wrong? - UnknownFulcrum
Repeat to me what I and endurion said. :rolleyes:

This topic is closed to new replies.

Advertisement