[Excerpt] in-depth brew Message Processing Mechanism

Message Processing Mechanism, that is, event driven is different from the traditional programming mechanism, such as DOS and C Programming in UNIX,ProgramThe process is not executed in sequence. Readers who have experience in Window Programming will understand this mechanism.

Message Processing Mechanism in Windows: when an action (or signal, or input, etc) is performed in the interaction, the window generates the corresponding event. Through the event dispatch mechanism in the window, the corresponding window or app gets the event, which triggers the corresponding event handler fun for processing.
In short, the Message Processing Mechanism in brew is similar, that is, after the brew environment (here is the aee shell) captures the event, dispatch to the corresponding app or control, which is processed by its event handler fun.
Difference: We know that brew's architecture adopts the com method, that is, it has an object-oriented class hierarchy, thus, the specific event handler fun is also used as an interface function exposed by each interface. An applet is essentially an instantiated iapplet class, so it unifies all the statements that the event handler fun used in the applet is the exposed interface function of each interface.
Specifically, there are differences between these event handler fun, mainly the differences between iapplet_handleevent and the handleevent of other interfaces.
Iapplet_handleevent is registered and instantiated through the aeeapplet_new function in aeeclscreateinstance. The aeeapplet_new function instantiates the user's Applet Class and instantiates the iapplet_handleevent by passing the userapp_handleevent parameter.
In addition to iapplet handleevent, all interfaces that inherit the iControl interface also have event processing functions that allow event processing. There are two methods to call these specific icontrol_handleevents. One is explicitly called by programmer in the handleevent of the applet, for example:
Switch (Ecode)
{
Case Evt_app_start:
.........
Return (True );
Case Evt_app_stop:
..........
Case evt_key:
Imenu_handleevent ....
Itextctl_handleevent ....

the other is that when these controls are included in the dialog and are in the focus state, the trigger of these event processing functions is implicit and is automatically triggered by the aee mechanism, you do not need to explicitly call these handleevents in Code .
the idialog interface does not have the exposed handleevent interface function, however, you can use idialog_seteventhandle to register an event handler for this dialog. It should be noted that when the event processing function is triggered: Once a dialog is active, aee shell will send all the events directly to the dialog, the dialog automatically calls the handleevent of the control in focus to process the event. Only when the control does not process the event will the registered event processing function of dialog be called.

The handle event function in brew is of the Boolean return type, which is used to implement the layered mechanism of event processing. When the handle event on this layer does not process the event, false should be returned, so that the upper-layer handle event interested in this event can be processed. If yes, true is returned, indicating that the event has been processed and no other layer is needed.

 

With the above knowledge, the following describes the complete process of message distribution and processing in the brew environment.
First, brew exists in a task. Although brew is allowed to run in a separate task, the actual OEM runs it in an existing task, such as a UI task.
After brew runs, various events are captured in the UI task. At this time, the UI task distributes the events to the brew environment through aee_dispatch, and then the brew environment distributes the events to the destination through aee_sentevent. In two different cases, different procedures will be followed.
If no active dialog is available, the iapplet_handleevent is automatically called by brew to handle the event. At this time, the iapplet_handleevent called is actually the user-registered applet_handleevent. This allows the app to capture and process events. In the app handleevent of a user, the user can issue events, for example, issue events to various controls by calling imenu_handleevent.
If there is active dialog, then the adialog_event is automatically called by brew, so that the event is intercepted first by dialog, and the processing after dialog is to check which of the included controls is in focus, the event is sent to its handleevent for processing, and its return value is used to determine whether the event has been processed. When it returns false, dialog forwards the event to the handleevent registered by Dialog (if any). If the handleevent still returns false, brew forwards the event to the app handleevent. This mechanism makes various events automatically processed when an application is created using dialog, which simplifies the amount of code, but makes the event process even more obscure, your program cannot directly control it.
Finally, I will combine a problem in my work to deepen my understanding of the brew event processing mechanism.
This is a question about the input method. when inputting in textctl, if it is pinyin or strokes, the situation is more complicated, roughly as follows:
APP handleevent calls itextctl_handleevent to process key events. In the OEM Implementation of itextctl_handleevent, A pinyin Dialog (pinyindlg) is created to display input Pinyin and candidate words, and a dialoghandler (pinyindlgevent) is registered ), pinyindlg contains a control (ipinyinmanager). Its handleevent (ipinyinmanager_handleevent) is mainly used to process a series of complex tasks such as how to display candidate words when a user inputs pinyin.
In this case, when the Pinyin input mode is used, after the first letter is entered, pinyindlg is created to display the candidate word, and ipinyinmanager_handleevent is activated, after that, the ipinyinmanager_handleevent will be directly called for processing by pressing any key, and the handleevent returns true, indicating that the processing is correct.
In this way, all key events will be intercepted by ipinyinmanager_handleevent, and the app and itextctl will not be able to process the events. Then how can we return it to text control? For other operations, such as deletion, switching, and saving.
This is achieved through special processing of special keys in ipinyinmanager_handleevent. For example, if the CLR is defined as return to text control, return false when the key is avk_clr in ipinyinmanager_handleevent, therefore, the pinyindlgevent registered by pinyindlg has the opportunity to be called, and the release pinyindlg in this handleevent returns true. In this way, the DLG is release, so that the next button can be captured by the app, and the app handleevent is sent to the itextctl_handleevent, so that the focus of event processing is returned to the itextctl. Here, return true is used to avoid deleting the last Chinese character at the same time. (If false causes itextctl_handleevent to process the CLR again, a Chinese character is deleted ).
We know that the application can set maxchars to limit the maximum number of characters entered in text. It is okay when the input is a letter, number, or symbol. However, when the input is pinyin, when the maximum number of input is reached, the text cannot be entered, but the pinyin DLG continues to exist, as the buttons continue to respond, for example, the candidate words are constantly changing ). This is because in the OEM layer, when the input reaches the maximum value, it simply does not store characters in the text buffer, but does not: Release drops pinyindlg and returns to the text control, does not respond to any input of these features.
How can this problem be solved? If you are familiar with the brew event processing mechanism, the problem will be solved. You only need to release the event processing control when the input reaches the maximum number, so that the next event processing will be captured by the app again and sent to itextctl, in the OEM Implementation of handleevent of itextctl, when the maximum input is reached, no response is made. The details are as follows:
ipinyinmanager_handleevent processes the select event, mainly adding Char to text. After processing the Add char, we add a judgment on whether the maximum input number is reached, if the maximum number is reached, return false to release the control of event handle. Then, the pinyindlgevent registered by pinyindlg will continue to process this event (that is, the select key), and release pinyindlg in this eventhandle so that it will not be displayed, returns true at the same time (this is to prevent the select event from being passed to the app; otherwise, the app may save the event ). In this way, the next key will be successfully transmitted to itextctl_handleevent. In the OEM implementation of this handleevent, we add a judgment on the maximum number of inputs. If the maximum number is reached, no response will be made, at the same time, true is returned (only for the program, indeed a response is made :)). In this way, the pinyin box is automatically hidden when the input reaches the maximum number, and then no response is made by pressing any key.