Author: liigo
Link: http://blog.csdn.net/liigo/archive/2010/10/28/5972548.aspx
Reprinted please indicate the source: http://blog.csdn.net/liigo
Liigo: "easy language. Dust" interface library version 2.0 Source Code Analysis Series
We are glad to see that the original and easy language module of "easy language. Dust" has been upgraded in the near future, and the version has reached 2.1. It seems that I have to continue to follow up on this source code analysis series. This latest article focuses on the Windows message routing mechanism in the interface library. Windows messages (such as wm_paint) are generated by the Windows operating system and sent to the corresponding Windows message processing function (wndproc ). Based on the previous analysis, we know that the message is distributed to the corresponding window object by edust_wndproc () in the module () "method (inherited from" _ window base class "). How will Windows messages be processed next? This article will reveal the answer.
Let's start with "_ window base class. Message process ()" and see what code is in it:
To understand the above Code, it is best to first understand the role of the "event hash table" member variable. Literally, it should be a set of "key-value" in a hash table. Its "key" is the message value. What is its "value? Is it a subprogram for message processing? Press Ctrl + F to search for "event hash table" and find the member method of "_ window base class. Hook event ()". The Code is as follows:
From the above Code, we know that the "key" of the "event hash table" is the event type (Windows message value), and the "value" is a collection of linked lists-event processing subprograms. Obviously, the event processing subroutine is provided by the message handler and will be automatically called by the class library. How is the event processing subroutine called? In other words, how is a Windows message processed? Let us look back to the "_ window base class. the "event linked list _ processing ()" subprogram called in the message process () "is assumed to be a cyclic traversal table that calls the corresponding event processing subprogram in sequence, the processing is not completed until the traversal is completed or the processing of an event processing subroutine is required. The event processing subroutine is called, which means that the message value (event) is processed. In fact, the subsequent processing subroutine is called first, that is, the circular traversal table mentioned above should actually be in reverse order traversal. This detail may be involved in the future, and no code will be posted for the time being.
Well, it's time to summarize the event processing mechanism in the "easy language. Dust" interface library 2.0 (that is, the Windows Message Processing Mechanism): 1._ Window base class. Hook event ()"Records the message values to be processed and their processing subroutines, and records them in the" event hash table "of the class member variable. 2."_ Window base class. Message process ()By querying the "event hash table", you can obtain and call the event processing subroutine that is attached to the current message value. Additionally, you can call the _ window base class multiple times. mounting event () "mounts multiple event processing subprograms to the same Windows message value. Then, the following event processing subprograms will be called first, the subsequent event processing subroutine determines whether to call the previously attached event processing subroutine.
The above is the basic event processing mechanism of the "easy language. Dust" interface library 2.0, which is also the basic part of its message routing mechanism. In addition to the fact that end users of the class library can use this event processing mechanism to process Windows messages, the Class Library also uses this event processing tool to process many more in-depth messages, which will be left to be broken down below.