Message-based, event-driven

WindowsProgramDepends on the externalEventComeDriver. In other words, the program keeps waiting (using a while loop ),Wait for any possible inputAnd then doJudgmentAnd then make the appropriateProcessing.

The preceding"Lose"」YesbyOperating SystemCaptureToMessageForm (a Data Structure) enters the program.

The operating system passesUser Module(One of the three windows modules)CaptureEvents that occur on peripheral devices (such as the keyboard and mouse.

Two types of input obtained by the application:

ByHardwareMessages generated by the device (such as moving the mouse or pressing the keyboard) are placed inSystem queue)Medium

By windowsSystemOr otherWindowsProgramThe sent message is placed inApplication queue).

From the application's perspective, a message is a message. There is no big difference in where it comes from or where it is stored.The getmessage API gets a message, and the life of the program is promoted by it.

All GUI systems, including unix x Windows and OS/2 Presentation manager, are like this. They are message-based event-driven systems.

It is conceivable that every Windows program should have a loop as follows:

 1   MSG;  2   While (Getmessage (& MSG, null )){  3 Translatemessage (& MSG );  4 Dispatchmessage (& MSG );  5   }  6   7   //  The above functions are all Windows API function messages, that is, the MSG structure shown above, which is actually a data format defined in Windows:  8   /*  Queued message structure */  9 Typedef Struct  Tagmsg  10   {  11   Hwnd;  12 Uint message; //  Wm_xxx, such as wm_mousemove, wm_size...  13   Wparam;  14   Lparam;  15  DWORD time;  16   Point pt;  17 } MSG;