Did you know?

[3pj6b7Xj]

That windows does not place the WM_SYSCOMMAND message or the WM_DESTROY message in the queue? If you try to intercept these messages in the message by via Msg.messages==WM_SYSCOMMAND; you will NEVER see the message because it is actually sent directly to your windows procedure! Thats why your PROC can pick it up but your message pump can't! Funny eh?

When a window closes, windows sends a WM_SYSCOMMAND message with SC_CLOSE in the wParam section into your window procedure, then a WM_DESTROY message is sent.

For people who use peekmessage() for games, your probably frustrated as to why your program wont quit with Msg.message==WM_QUIT well, there is no quit message when the window is closed!!

MSG Msg;
while(Msg.message!=WM_QUIT)
{
if(PeekMessage(&Msg,NULL,0,0,PM_REMOVE) // is there a message?
{
TranslateMessage(&Msg); // translate the message.
DispatchMessage(&Msg); // pump the message to procedure.
}

// then, what to do when there are no messages...
}

This alone wont help, as you need the following in your proc. You can do
this 2 ways.

LRESULT CALLBACK YourProc
(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch(Msg) // pumped messages come out here.
{
case WM_DESTROY:
{
PostQuitMessage(0); // place a WM_QUIT message in queue.
break;
}
// handle non-trapped messages.
deault:DefWindowProc(hWnd,Msg,wParam,lParam);
}

return 0; // indicates a message was trapped.
}

This works fine but you can also do it by trapping the HIGH priority message from WM_SYSCOMMAND...

LRESULT CALLBACK YourProc
(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch(Msg) // pumped messages come out here.
{
case WM_SYSCOMMAND:
{
if((wParam&0xFF0)==SC_CLOSE)
{
PostQuitMessage(0); // place a WM_QUIT message in queue.
break;
}
}
// handle non-trapped messages.
deault:DefWindowProc(hWnd,Msg,wParam,lParam);
}

return 0; // indicates a message was trapped.
}

sO WHAT is the difference?? Simple, one message has less priority than another...you should really intercept WM_SYSCOMMAND but if you want to be lazy, you can always just check WM_DESTROY....the bottom line is, when your window is closed, you need to relay this event to your message pump so that you take proper action..

The reason your program closes with a regular GetMessage() pump is because WM_QUIT is intercepted in the procedure, this WM_QUIT message is posted by DefWindowProc when the WM_SYSCOMMAND message shows up...just stuff that happens behind the scenes.

This is hot topic around here I think. This information is scattered across the win32 api at MSN, HIGH priority messages AREN'T placed in the queue, they are sent directly to your window procedure...WM_CREATE is one such message, this will NEVER be placed in the queue of messages, instead, windows sends the message directly to your window procedure and if you trap it, you'll find it.

Just wanted to share this, hope it helps some people, sorry for not using the code enclosure <code></code>.

[guestgulkan]

If you don't trap the case WM_SYSCOMMAND::SC_CLOSE message and let it go onto the DeWindowProc - the DefWindowProc will send a WM_CLOSE message anyway.

The default windows procedure for WM_CLOSE is to destroy the window and send a WM_DESTROY message.

Posting a WM_QUIT messge is the programmers responsibilty - if you don't post it you will find that your window has gone, but your program is still running because you haven't broken out
of the GetMessage loop.

[3pj6b7Xj]

thanks for pitching in guestgulkan, hopefully others can add to this.