如何正确的使用PeekMessage()

HOWTO: How to Use PeekMessage() Correctly in Windows

SUMMARY

In the Windows environment, many applications use a PeekMessage()loop to perform background processing. Such applications must allow theWindows system to enter an idle state when their background processingis complete. Otherwise, system performance, "idle-time" systemprocesses such as paging optimizations, and power management onbattery-powered systems will be adversely affected.

While an application is in a PeekMessage() loop, the Windows system cannot go idle. Therefore, an application should not remain in a PeekMessage() loop after its background processing has completed.

NOTE:The PeekMessage method described in this article is only needed if yourapplication is a 32-bit application for Windows and is, for somereason, unable to create threads and perform background processing.

MORE INFORMATION

Many Windows-based applications use PeekMessage()to retrieve messages while they are in the middle of a long process,such as printing, repaginating, or recalculating, that must be done "inthe background." PeekMessage() is used in these situations because, unlike GetMessage(), it does not wait for a message to be placed in the queue before it returns.

An application should not call PeekMessage() unless it has background processing to do between the calls to PeekMessage(). When an application is waiting for an input event, it should call GetMessage() or WaitMessage().

Remaining in a PeekMessage() loop when there is no background work causes system performance problems. A program in a PeekMessage() loop continues to be rescheduled by the Windows scheduler, consuming CPU time and taking time away from other processes.

Inenhanced mode, the Virtual Machine (VM) in which Windows is runningwill not appear to be idle as long as an application is calling the PeekMessage function. Therefore, the Windows VM will continue to receive a considerable fraction of CPU time.

Manypower management methods employed on laptop and notebook computers arebased on the system going idle when there is no processing to do. Anapplication that remains in a PeekMessage() loop willmake the system appear busy to power management software, resulting inexcessive power consumption and shortening the time that the user canrun the system.

In the future, the Windows system will makemore and more use of idle time to do background processing, which isdesigned to optimize system performance. Applications that do not allowthe system to go idle will adversely affect the performance of thesetechniques.

All these problems can be avoided by calling the PeekMessage() function only when there is background work to do, and calling GetMessage() or WaitMessage() when there is no background work to do.

For example, consider the following PeekMessage()loop. If there is no background processing to do, this loop willcontinue to run without waiting for messages, preventing the systemfrom going idle and causing the negative effects described above.

   // This PeekMessage loop will NOT let the system go idle.

   for( ;; )
   {

      while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
      {
         if (msg.message == WM_QUIT)
            return TRUE;

         TranslateMessage(&msg);
         DispatchMessage(&msg);
      }

      BackgroundProcessing();
    }

This loop can be rewritten in two ways, as shown below. Both of the following PeekMessage() loops have two desirable properties:

• They process all input messages before performing background processing, providing good response to user input. • The application "idles" (waits for an input message) when no background processing needs to be done.

 

Improved PeekMessage Loop 1

   // Improved PeekMessage() loop

   for(;;)
   {

      while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
      {
         if (msg.message == WM_QUIT)
            return TRUE;

         TranslateMessage(&msg);
         DispatchMessage(&msg);
      }

      if (IfBackgroundProcessingRequired())
         BackgroundProcessing();
      else
         WaitMessage(); // Will not return until a message is posted.

   }

Improved PeekMessage Loop 2

   // Another improved PeekMessage() loop

   for (;;)
   {

      for (;;)
      {
         if (IfBackgroundProcessingRequired())
         {
            if (!PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
               break;
         }
         else
            GetMessage(&msg, NULL, 0, 0, 0);

         if (msg.message == WM_QUIT)
            return TRUE;

         TranslateMessage(&msg);
         DispatchMessage(&msg);
      }
      BackgroundProcessing();

   }

Note that calls to functions such as IsDialogMessage() and TranslateAccelerator() can be added to these loops as appropriate.

Thereis one case in which the loops above need additional support: if theapplication waits for input from a device (for example, a fax board)that does not send standard Windows messages. For the reasons outlinedabove, a Windows-based application should not use a PeekMessage()loop to continuously poll the device. Rather, implement an InterruptService Routine (ISR) in a Dynamic-Link Library (DLL). When the ISR iscalled, the DLL can use the PostMessage function to inform the application that the device requires service. DLL functions can safely call the PostMessage() function because the PostMessage() function is reentrant.

From: http://blog.csdn.net/baofeng/archive/2007/01/20/1488360.aspx