INFO: Handling WM_QUIT While Not in Primary GetMessage() Loop (89738)

MORE INFORMATION

An application can get into a secondary message loop that is different from the primary GetMessage() loop in order to track drag messages, yield periodically during lengthy processing, and so on. The user may be able to terminate the application while the secondary message loop is being used to retrieve messages from the message queue.

If the GetMessage()/PeekMessage() call used in the secondary loop specifies a message filter that does not include WM_QUIT, WM_QUIT will not be retrieved from the message queue. When the loop terminates, control will be returned to the primary GetMessage() loop, which retrieves the WM_QUIT message.

If the GetMessage()/PeekMessage() call in the secondary loop retrieves all messages or specifies a message filter that includes the WM_QUIT message, the WM_QUIT message that is retrieved must be reposted and control must be returned to the primary message loop. The primary message loop will then retrieve the reposted WM_QUIT message and exit.

   while (bNotDone)
   {

   // Secondary message loop
   while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
   {
      if (msg.message == WM_QUIT)
      {
         // Repost the QUIT message so that it will be retrieved by the
         // primary GetMessage() loop.
         PostQuitMessage(msg.wParam);
         return FALSE;
      }
      // Pre-process message if required (TranslateAccelerator etc.)
      TranslateMessage(&msg);
      DispatchMessage(&msg);
      :
      :
   }
   :

}
				

The primary message loop will not exit if the secondary message loop does not repost the WM_QUIT message. Consequently, the application will remain in memory even though all its windows are destroyed.

An alternative solution is to prevent the user from terminating the application while the application is in the secondary message loop.