訊息處理機制，即event driven和傳統的程式設計機制不同，如dos，unix下的c程式設計，他沒有main loop，程式的流程不是順序執行的。有過window程式設計經歷的讀者都會清楚這種機制。
switch (ecode)
{………
return(true);
……….
case evt_key:
imenu_handleevent….
itextctl_handleevent….
另一種是當這些control包含於dialog中，且處於focus狀態時，這些事件處理函式的觸發是隱式的，是由aee機制自動觸發的，無需在**中顯式的呼叫這些handleevent。
idialog介面沒有外露的handleevent介面函式，但是允許通過idialog_seteventhandle來註冊乙個該dialog的事件處理函式。需要注意的是，該事件處理函式是何時被觸發的：一旦當乙個dialog處於active時，aee shell將會把所有的event直接發往該dialog，該dialog會自動的呼叫處於focus的control的handleevent來處理該事件，只有當該control沒有處理該事件時，dialog註冊的事件處理函式才會被呼叫。
brew中的handle event函式都是boolean返回型別的，這是為了實現事件處理的層次機制，當該層上的handle event沒有處理該事件時，應該返回false，以便上層對該事件感興趣的handle event來處理。 如果處理了，應該返回true，說明該事件已被處理，無需其他層再處理。
有了以上知識後，下面給出完整的brew環境下訊息分發和處理的流程。
首先brew存在於乙個task中，儘管允許brew執行於乙個單獨的task中，但是實際oem中都是將其執行於現有的乙個task中，比如ui task。
當brew執行後，首先ui task中捕捉到各種事件，此時ui task通過aee_dispatch將事件分發至brew環境中，brew環境再通過aee_sentevent具體分發事件至目的地。接著在兩種不同的情況下將走不同的流程。
最後，結合乙個我工作中的問題，來加深對brew事件處理機制的理解。
這是乙個關於輸入法的問題，當在textctl中進行輸入時，如果是拼音和筆畫輸入時，情況比較複雜，大致如下：
這樣的話，當處於拼音輸入模式時，輸入第乙個字母後，就建立了pinyindlg來顯示候選字，同時ipinyinmanager_handleevent被啟用，之後按的任何鍵都會直接呼叫該ipinyinmanager_handleevent來處理，且該handleevent均返回true，表示正確處理了。
我們知道，應用可以設定maxchars來限制text中輸入的最大字元數。當輸入為字母，數字，符號時沒有問題。但是當輸入為拼音時，當達到最大輸入數時會出現一種情況，就是不能輸入進text了，但是拼音dlg繼續存在，且隨著不斷的按鍵繼續有不斷的響應（比如候選字不斷變化等）。這是由於oem層當輸入達到最大值時的處理是，僅僅不往text buffer中存入字元而並沒有實現：release掉pinyindlg，回到text 控制下，不響應使用者任何輸入這些功能。
以上是我一段時間工作後的心得體會，可能有不當之處，大家相互交流。
--
BREW開發教程 4 BREW訊息處理機制
uint32 dwparam 第三和第四分別為16位和32位與事件相關的資料，這些值是與具體的事件相關的。鍵盤事件描述 evt key press evt key release evt key 在對話方塊中通過方向鍵來移動游標的方向取決於哪種控制項具有焦點以及使用者按了哪個方向 上 下 左 右 鍵...
BREW開發教程 4 BREW訊息處理機制
uint32 dwparam 第三和第四分別為16位和32位與事件相關的資料，這些值是與具體的事件相關的。鍵盤事件描述 evt key press evt key release evt key 在對話方塊中通過方向鍵來移動游標的方向取決於哪種控制項具有焦點以及使用者按了哪個方向 上 下 左 右 鍵...
handler訊息處理機制
handler主要用來更新ui 因為涉及到執行緒安全，android必須在ui執行緒 即主線程 裡才能更新ui，在其他執行緒裡更新ui會報錯，而一些耗時的操作又必須通過開啟新的執行緒來執行，這就要用到handler來傳遞訊息了。在主線程中建立乙個handler的例項，並重寫handlermessag...