Category : Tutorials + Patches
Archive   : WINTSR.ZIP
Filename : WINIDLE1.TXT

Knowledge Base+
Title: INF: How to Use PeekMessage Correctly in Windows
Document Number: Q74042 Publ Date: 23-APR-1993
Product Name: Microsoft Windows Software Development Kit
Product Version: 3.00 3.10
Operating System: WINDOWS

----------------------------------------------------------------------
The information in this article applies to:
- Microsoft Windows Software Development Kit for Windows versions 3.1
and 3.0
----------------------------------------------------------------------
Summary:
In the Windows environment, many applications use a PeekMessage loop
to perform background processing. Such applications must allow the
Windows system to enter an idle state when their background processing
is complete. Otherwise, system performance, "idle-time" system
processes such as paging optimizations, and power management on
battery-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.
More Information:
Many Windows applications use the PeekMessage function to retrieve
messages while they are in the middle of a long process, such as printing,
repaginating, or recalculating, that must be done "in the background."
The PeekMessage function is used in these situations because, unlike
the GetMessage function, it does not wait for a message to be placed
in the queue before it returns.
An application should not call the PeekMessage function unless it has
background processing to do between the calls to the PeekMessage
function. When an application is waiting for an input event, it should
call the GetMessage or WaitMessage functions.
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.
In enhanced mode, the virtual machine (VM) in which Windows is running
will 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.
Many power management methods employed on laptop and notebook
computers are based on the system going idle when there is no
processing to do. An application that remains in a PeekMessage loop
will make the system appear busy to power management software,
resulting in excessive power consumption and shortening the time that
the user can run the system.
In the future, the Windows system will make more and more use of idle
time to do background processing, which is designed to optimize system
performance. Applications that do not allow the system to go idle will
adversely affect the performance of these techniques.
All these problems can be avoided by calling the PeekMessage
function only when there is background work to do, and calling the
GetMessage or WaitMessage functions 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 will continue to run without
waiting for messages, preventing the system from 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.
There is one case in which the loops above need additional support: if
the application waits for input from a device (for example, a fax
board) that does not send standard Windows messages. For the reasons
outlined above, a Windows application should not use a PeekMessage
loop to continuously poll the device. Rather, implement an interrupt
service routine (ISR) in a dynamic-link library (DLL). When the ISR is
called, 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.
For more information about background processing in applications
running in the Windows environment, including references to sample

source code, query this knowledge base on the following words:
prod(winsdk) and backproc
Additional reference words: 3.00 3.10 3.x backproc
KBCategory:
KBSubcategory: UsrMsgGetmsg

COPYRIGHT Microsoft Corporation, 1992.