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.