38.9.5.5 Windows Message Processing
Many Windows programs are event-driven programs that display
dialogs and output sounds corresponding to events such as "clicking
an icon," "moving the mouse," and "pressing a key".
When any such event occurs, Windows sends the application a
message that indicates the type of event. Upon receiving the
message, the applications acknowledge that the event has occurred
and execute the processing.
In this document, the part that receives messages in order from
Windows and branches them into the respective processing (DoEvents,
in VB, and the part where GetMessage() and DispatchMessage() are
performed in VC) is called the message pump.
When normally programmed in VC and VB, the message pump hides in
the VC and VB framework. If the message pump does not perform
properly, Windows applications perform unintended operations.
For example, if a routine takes a long time to process a message
and does not return, the application cannot receive an event from
Windows during the processing time and cannot process the
event.
For example, when Windows sends messages in the order of Message
1 and Message 2. The message pump retrieves Message 1 and calls a
subroutine for Message 1.
Once returning, it retrieves the next message (Message 2) and
calls a subroutine for Message 2.
If it takes a long time to process Message 1 at this point, the
message pump does not return and the message pump processing 2
cannot be performed.
In such case, force the operation of the message pump. (Referred
to DoEvents in VB and GetMessage() and DispatchMessage() in ,
VC)
Windows applications are designed based on applications to
operate the message pump properly. In order to prevent such an
event as shown in the example, WinGP SDK operates the message pump
in the function when processing takes too long.
|
