Archived

This topic is now archived and is closed to further replies.

SikCiv

Catching ALT-F4

Recommended Posts

You disable it not responing to the messages in the first place, although you need to think about WHY you would want to do this.

WM_DESTROY is sent after the window is removed from the screen, but before child windows are destoyed.

Share this post


Link to post
Share on other sites
null_pointer    289
WM_QUIT - tells the app to quit.
WM_CLOSE - tells a window it is being closed.
WM_DESTROY - tells a window it is being destroyed.

The most typical way of handling shutdown is to destroy the app when the user closes the window (by pressing the X button in the upper right corner). You do this by calling DestroyWindow(), which destroys your app''s window, and then by calling PostQuitMessage(), which places a WM_QUIT in the message queue so that your main message loop will find it on the next pass.

Example:


int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
// TODO: Place app startup code here

MSG msg; // allocate storage for one message and parameters

for( ;; ) // loop "forever"
{
// Remove a message from the queue and place it in our storage
GetMessage(0, &msg, 0, 0);

// Only a WM_QUIT message can break the loop
if( msg.message == WM_QUIT ) break;

// Send it off to the WndProc
TranslateMessage(&msg);
DispatchMessage(&msg);
}

// TODO: Place app shutdown code here
}


LRESULT CALLBACK WndProc(HWND hWnd, UINT nMsg, WPARAM wParam, LPARAM lParam)
{
switch( nMsg )
{
case WM_CLOSE:
// Sends us a WM_DESTROY
DestroyWindow(hWnd);
return 0;

case WM_DESTROY:
// Send a WM_QUIT to the main loop, ends the loop and returns from WinMain
PostQuitMessage(0);
return 0;

default:
// Let Windows take care of the other messages
return DefWindowProc(hWnd, nMsg, wParam, lParam);
}
}



So the usual order is:
WM_CLOSE -> WM_DESTROY -> WM_QUIT -> (program ends)

You should only change this order around if you know what you are doing. Games typically use a slightly more complex main loop, which uses PeekMessage function and the WM_ACTIVATE message, so that they can juggle CPU time more efficiently. I can explain this if you want, just let me know.

Share this post


Link to post
Share on other sites
null_pointer    289
Oh, as NuffSaid alluded to, WM_CLOSE doesn't simply correspond to the close button on the window. There are many ways of closing a window, so Windows just sends you a WM_CLOSE message when any of those methods is used. Here are some examples:


  • Clicking the close button on the title bar

  • Selecting the Close menu item from the window's system menu

  • Double-clicking the window's icon

  • Pressing ALT+F4



(This abstraction is cool, because the Windows team could change the GUI all around, or invent new ways of closing a window (a fourth mouse button?) in the future and correctly written programs will still work as expected. This is one of the reasons why many Win16 apps worked with Win32 when Windows 95 was released.)


Edited by - null_pointer on March 21, 2001 8:56:59 AM

Share this post


Link to post
Share on other sites
SikCiv    122
My app isnt MFC based, its DirectDraw based so whenever the user presses ALT-F4 the app would just close without unloading DirectX, resulting in a DDHelp crash.

From what ive read, my guess is I need to add WM_CLOSE and put my destruction code in there. Thanks for the help.

Share this post


Link to post
Share on other sites