note: 一般用postthreadmessage函式傳送執行緒之間的訊息，他和視窗訊息不同，需要指定執行緒id,訊息被系統放入到目標執行緒的訊息佇列中；用on_thread_message( message, memberfxn )巨集可以對映執行緒訊息和他的處理函式。這個巨集必須在應用程式類(從cwinthread繼承)中，因為只有應用程式類才處理執行緒訊息。
訊息的目標視窗的pretranslatemessage函式首先得到訊息處理權，如果函式返回false，那麼他的父視窗將得到訊息的處理權，直到主視窗；如果函式返回true(表示訊息已經被處理了)，那麼就不需要呼叫父類的pretranslatemessage函式。這樣，保證了訊息的目標視窗以及他的父視窗都可以有機會呼叫pretranslatemessage--在訊息傳送到視窗之前進行預處理 如果訊息的目標視窗和主視窗沒有父子關係，那麼再呼叫主視窗的pretranslatemessage函式。例如非模式對話方塊
訊息路由/對映
到現在訊息已經被目標視窗得到了。
主要分2種情況去找處理函式：wm_command,wm_notify處理類似
note:mfc 把訊息分為三大類：
命令訊息（wm_command）：凡由ui 物件產生的訊息都是這種命令訊息，可能來自選單或加速鍵或工具欄。sdk程式主要靠訊息的wparam 辨識之，mfc 程式則主要靠選單項目的識別碼（menu id）辨識之-- 兩者其實是相同的。
凡衍生自ccmdtarget 的類別，皆有資格接收改型別訊息。幾乎構造應用程式的最重要的幾個類別都衍生自ccmdtarget。標準訊息- 除wm_command 之外，任何以wm_ 開頭的都算是這一類。任何
衍生自cwnd 之類別，均可接收此訊息。control notification - 這種訊息由控制項產生，為的是向其父視窗通知某種情況。例如當你在listbox 上選擇其中乙個專案，listbox 就
會產生lbn_selchange 傳送給父視窗。這類訊息也是以wm_command 形
式呈現。
「標準訊息」處理最直觀，直接呼叫afxfindmessageentry函式去「訊息對映表」中尋找對應的處理函式。遍歷順序是沿著父類一直上溯。其中訊息對映表是mfc**類似於declare_message_map()等的巨集搭建起來的網。
按照mfc的規定。wm_command訊息就不同了，訊息經過了乙個由mfc指定的路線。
路線圖如下所示：
就是在oncmdmsg(nid, ncode, pextra, phandlerinfo)實現了這個路線。
至此。訊息處理全部完成。全圖如下：
其他備註：
只要執行緒有介面元素或者呼叫getmessage,或者有執行緒訊息傳送過來，系統就會為執行緒建立乙個訊息佇列。視窗屬於建立他的執行緒。用sendmessage等傳送訊息到指定視窗，則把該訊息放到視窗所在的訊息佇列。或者可以直接用postthreadmessage給指定id執行緒傳送訊息。 ::peekmessage(&msg,null,0,0,pm_noremove)的最後乙個引數指定檢查訊息後，把不把訊息移出訊息佇列。 關注onidle函式：在cthreadwnd發現訊息佇列中並沒有訊息的時候，則呼叫該函式。使用者可過載該函式。在這個處理中將更新ui介面(比如工具欄按鈕的enable和disable狀態)，刪除臨時物件(比如用fromhandle得到的物件指標。由於這個原因，在函式之間傳遞由fromhandle得到的物件指標是不安全的，因為他沒有永續性)
MFC 訊息機制
windows應用程式是通過訊息驅動的，在mfc軟體開發時，進行介面操作經常要用到訊息，通過訊息對應的處理函式來實現響應的操作。比如，使用者操作視窗，就會產生訊息，送給對應的訊息處理函式進行處理，對使用者的操作做出一些反應。mfc使用訊息對映機制來處理訊息，具體表現就是訊息和訊息處理函式一一對應的訊...
MFC訊息機制
一 訊息的分類 1 佇列訊息 非佇列訊息 l佇列訊息 windows 為每個應用程式都建立乙個訊息佇列，那麼通過訊息佇列，進行傳送的訊息都屬於佇列訊息 一般來說，由滑鼠 鍵盤產生的訊息都屬於佇列訊息。為什麼呢？想想，滑鼠 鍵盤事件都是由系統捕獲的，系統捕獲後要傳遞給應用程式，就一定的通過訊息佇列 l...
MFC的訊息機制
今天重新整理mfc的訊息機制，最終的結果應該是利用win32程式模擬乙個mfc的訊息鏈。1.標準訊息 除wm command之外，所有以wm 開頭的訊息。從cwnd派生的類，都可以接收到這類訊息。2.命令訊息 來自選單 加速鍵或工具欄按鈕的訊息。這類訊息都以wm command呈現。在mfc中，通過...