Read the third chapter, mainly introduction is Windows message loop mechanism: Windows maintains a "message queue" for each Windows program currently executed. After the input event occurs, Windows converts the event into a "message" and puts the message into the program's message queue.
The program removes the message from the message queue by executing a program code called "message loop":
While (GetMessage (& MSG, NULL, 0, 0)) {TranslateMessage (& MSG); DispatchMessage (& MSG);
The message loop starts with a GetMessage call, which removes a message from the message queue:
GetMessage (& MSG, NULL, 0, 0)
As long as the Message field that removes the message from the message queue is not WM_QUIT (its value is 0x0012), GetMessage will pass a non-zero value. The WM_QUIT message will cause getMessage to pass back 0.
TranslateMessage (& MSG); Pass the MSG structure to Windows, perform some keyboard conversion.
DispatchMessage (& MSG); also returns the MSG structure to Windows. Then Windows sends the message to the appropriate window message handler to process it. That is to say, Windows will call the window message handler. After processing the message, the window message handler is sent back to Windows. At this point, Windows also stays in the DispatchMessage call. After ending the DISPATCHMESSAGE call, Windows returns to the main program and then starts the message loop from the next GetMessage call.
This is a mechanism that is completely different from the past style. In the past, we call the operating system to complete some tasks, for example, the C program writer opens the file using the FOPEN function. The FOPEN function ultimately opens the file by calling the operating system, this problem is not. But Windows is different, but it not only provides thousands of functions for program calls, but also calls the user program. Although the Windows program can be executed multithreaded, each executionful message queue processes the window processing message for the window message handler in the execution. In other words, the message loop and window message handler are not executed concurrently. When a message loop receives a message from its message queue, then call DispatchMessage When sending the message to the window message handler until the window message handler converts the control back to Windows, DispatchMessage ends the execution.
Now let's take a look at the whole process of a simple Windows program:
1. Register the window category registerclass function to register a window category, which takes a parameter, the type of Wndclass's structural pointer, where WNDCLASS contains 10 fields, describes a series of features, the most important feature is its dependency window Message handler 2. Create a window CREATEWINDOW function to instantiate a window, which is included primarily to some properties of the window (Name, Caption, Style, Postion), and instance name 3. Display window showWindow (hwnd, Icmdshow) on the screen; // The first parameter is the handle of the window to be drawn, the second parameter is initially displayed on the screen (general, maximum, minimization, etc.) UpdateWindow (hwnd) ); // will redraw the display area. It does this for a WM_PAINT message sent to the window message handler. Start Message Cyclic WHILE (GetMessage (& MSG, NULL, 0, 0)) {TranslateMessage (& MSG); DispatchMessage (& MSG);} 5. Message Processor LRESULT CALLBACK WNDPROC (HWND HWND, UINT MESSAGE, WPARAM WPARAM, LPARAM LPARAM) typically use Switch and CASE structures to determine what message is received by the window message handler, and how to properly process it. The window message handler must pass back when the message is processed. All messages that the window message handler not processed should be passed to the Windows function named DEFWINDOWPROC. The value from the DEFWINDOWPROC must be back by the window message handler. Note: WndProc is not processed, pass it to the DefWindowProc process, and send a new message to the WindowProc after the DefWindowProc response. If WindowProc can pass it to DEFWINDOWPROC, straightowProc can handle and proceed back. The above is a general framework of a Windows program. Although the sparrow is small, the five organizers are complete, and the message is also divided into the message and the non-queue message:
Queue messages are in the Windows in the program message queue. In the message loop of the program, it is retransmond and assigned to the window message handler. Non-queued messages directly to the window message handler when the Windows Call window. That is, the queue's message is "Send" to the message queue, not the queue, "Send" to the window message handler. In any case, the window message handler will get all the messages of the window - including queue and non-queue. The window message handler is the "Message Center" of the window.
I feel that this article mainly learns a simple Windows message mechanism, and it seems that this approach is necessary to waste certain resources in the middle, but the wasteful and get it seems to be ignored. It feels that this mechanism does not seem to be suitable for systems that carry heavy burden, purely. . . . .
Hey, I am looking at my dizzy, but finally I understand.
