🔒 Locked

How to test for WM_CLOSE message before Dispatching it ?

Started by Direct4D Nov 27, 2003 at 2:56 AM 9 replies 7k views

Original Post

Nov 27, 2003 at 2:56 AM

Okay i''m new to this forum, so first of all: Hi to everyone

Ok, to the business now... I''m working on some piece of window handling code. And i need to test for a WM_CLOSE message before i dispatch it to the message handler. I tried the following:

// following code is implemented in a class method

// receivedCloseMessage is a boolean class property


MSG msg;
while( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE )){
    if( WM_CLOSE == msg.message ) receivedCloseMessage = true;
    TranslateMessage( &msg );
    DispatchMessage( &msg );
}

But the WM_CLOSE message doesn''t seem to show up there. However it will show up in the message handler itself. I''m also not able to test for WM_DESTROY messages. Only message that i can seem to test for is the WM_QUIT message. Does anyone have a clue as to why i''m unable to find WM_CLOSE or WM_DESTROY messages in my message dispatching code ?

Nov 27, 2003 at 5:35 AM

Just handle the WM_CLOSE message in your message handler and set the flag there?

"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan

Londey

Nov 27, 2003 at 5:52 AM

I think WM_CLOSE and WM_DESTROY are associated with a particular window which your program could have many of. You need to pass the window handle into PeekMessage to receive those.

WM_QUIT will only be retrieved when the window handle passed is NULL because is it a message to the program not a specific window. This was causing me lots of problems when using the code from OpenGL Game Programming.

Direct4D

Nov 27, 2003 at 6:55 AM

Thx for the quick replies.

JY,
The reason i don't want to handle the WM_CLOSE in my message handler itself, is because i'm trying to build some sort of wrapper class for windows.
The message handler must either be a normal function or a static function inside that class.
I implemented it as an static function. But because it is static it doesn't know which WindowObject instance it is handling messages for.

However i was digging through the articles here on GameDev and i found an solution here:
Creating a Win32 Window Wrapper Class

I implemented it roughly in the same fashion now.

Londey,
I tried passing the window handle in the PeekMessage. But my WM_CLOSE messages still don't show up there

It's just as if WM_CLOSE messages get send to the message handler directly. But my logic tells me that that should not be the case.
I guess it will remain a mystery for me as to why i cannot find my WM_CLOSE messages.

[edited by - Direct4D on November 27, 2003 7:56:30 AM]

[edited by - Direct4D on November 27, 2003 7:56:49 AM]

[edited by - Direct4D on November 27, 2003 7:57:18 AM]

[edited by - Direct4D on November 27, 2003 7:57:48 AM]

Narcist

Nov 27, 2003 at 7:33 AM

tried putting a breakpoint in your message handler and looking at the callstack to see if it goes through your message dispatch or not?

Endurion

Nov 27, 2003 at 8:43 AM

Some messages are generated indirectly.
Means you will see some (but NOT all) messages in your loop.

Some of these messages get heavily processed by the defwindowproc; resulting in one or more other messages sent to your handler proc (e.g. WM_CLOSE). You will not get WM_CLOSE in a loop.

If you have only one general message pump for all your windows it''s enough to check for WM_QUIT.
If you have a message pump for only one window (which you shouldn''t unless that window is modal) you could get away with having a member variable of type HWND in the class and check if it is still valid (either set to NULL upon receiving WM_NCDESTROY in your handler or use IsWindow).

Nov 27, 2003 at 8:50 AM

Fair enough - so can you not call the static function with a pointer (or a reference) to the particular object you want it to manipulate?

"Absorb what is useful, reject what is useless, and add what is specifically your own." - Lee Jun Fan

Direct4D

Nov 27, 2003 at 11:47 PM

Ok thx again for all the replies.
It has given me some valuable new ideas on how to approach the problem.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.