windows消息机制详解-3
1. 引言
Windows 在操作系統平臺占有絕對統治地位，基于Windows 的編程和開發越來越廣泛。
Dos 是過程驅動的，而Windows 是事件驅動的[6]，這種差別的存在使得很多Dos 程序員不能
習慣Windows 的程序開發。而很多Windows 程序開發人員也只是對消息運行機制一知半解，
想要掌握Windows 編程的核心，必須深刻理解消息機制。事件驅動圍繞著消息的產生與處
理展開，事件驅動是靠消息循環機制來實現的。也可以理解為消息是一種報告有關事件發生
的通知，消息是Windows 操作系統的靈魂，掌握了消息運行機制就掌握了Windows 編程的
神兵利器。本文將首先闡述Windows 的編程原理，繼而對Windows 的消息運行機制進行分
析，并講述對消息的處理。MFC 是一個廣為使用的編程類庫，對Windows 的消息機制進行
了良好的封裝，所以，在第二部分將著重討論MFC 的消息映射，最后結合編程實際，通過
對MFC 消息映射的分析，非常巧妙的加以應用，以幫助解決實際問題
2. Windows 消息運行機制
在介紹Windows 消息運行機制之前，首先介紹一下消息的概念。
2.1 消息的概念和表示
消息（Message）指的就是Windows 操作系統發給應用程序的一個通告[5]，它告訴應用
程序某個特定的事件發生了。比如，用戶單擊鼠標或按鍵都會引發Windows 系統發送相應
的消息。最終處理消息的是應用程序的窗口函數，如果程序不負責處理的話系統將會作出默
認處理。
從數據結構[4]的角度來說，消息是一個結構體，它包含了消息的類型標識符以及其他的
一些附加信息。
系統定義的結構體MSG[1]用于表示消息，MSG 具有如下定義形式：
typedef struct tagMSG
{
HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
}MSG;
其中hwnd 是窗口的句柄，這個參數將決定由哪個窗口過程函數對消息進行處理；message
是一個消息常量，用來表示消息的類型；wParam 和lParam 都是32 位的附加信息，具體表
示什么內容，要視消息的類型而定；time 是消息發送的時間；pt 是消息發送時鼠標所在的位
置。
2.2 Windows 編程原理
Windows 是一消息（Message）驅動式系統，Windows 消息提供了應用程序與應用程序
之間、應用程序與Windows 系統之間進行通訊的手段。應用程序要實現的功能由消息來觸
發，并靠對消息的響應和處理來完成。Windows 系統中有兩種消息隊列，一種是系統消息隊
列，另一種是應用程序消息隊列。計算機的所有輸入設備由 Windows 監控，當一個事件發
生時，Windows 先將輸入的消息放入系統消息隊列中，然后再將輸入的消息拷貝到相應的應
用程序隊列中，應用程序中的消息循環從它的消息隊列中檢索每一個消息并發送給相應的窗
口函數中。一個事件的發生，到達處理它的窗口函數必須經歷上述過程。
所謂消息就是描述事件發生的信息，Windows 程序是事件驅動的，用這一方法編寫程序
避免了死板的操作模式，因為Windows 程序的執行順序將取決于事件的發生順序，具有不
可預知性。Windows 操作系統，計算機硬件，應用程序之間具有如圖1 所示的關系
?
?
箭頭1 說明操作系統能夠操縱輸入輸出設備，例如讓打印機打印；箭頭2 說明操作系統
能夠感知輸入輸出設備的狀態變化，如鼠標單擊，按鍵按下等，這就是操作系統和計算機硬
件之間的交互關系，應用程序開發者并不需要知道他們之間是如何做到的，我們需要了解的
操作系統與應用程序之間如何交互。箭頭3 是應用程序通知操作系統執行某個具體的操作，
這是通過調用操作系統的API 來實現的；操作系統能夠感知硬件的狀態變化，但是并不決
定如何處理，而是把這種變化轉交給應用程序，由應用程序決定如何處理，向上的箭頭4
說明了這種轉交情況，操作系統通過把每個事件都包裝成一個稱為消息結構體MSG 來實現
這個過程，也就是消息響應，要理解消息響應，首先需要了解消息的概念和表示。
2.3 Windows 消息循環
消息循環[1]是Windows 應用程序存在的根本，應用程序通過消息循環獲取各種消息，并
通過相應的窗口過程函數，對消息加以處理；正是這個消息循環使得一個應用程序能夠響應
外部的各種事件，所以消息循環往往是一個Windows 應用程序的核心部分。
Windows 的消息機制如圖2 所示：
?
?
Windows 操作系統為每個線程維持一個消息隊列，當事件產生時，操作系統感知這一事
件的發生，并包裝成消息發送到消息隊列，應用程序通過GetMessage()函數取得消息并存于
一個消息結構體中，然后通過一個TranslateMessage()和DispatchMessage()解釋和分發消息，
下面的代碼描述了Windows 的消息循環。
while(GetMessage (&msg, NULL, 0, 0))
{
TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}
TranslateMessage(&msg)對于大多數消息而言不起作用，但是有些消息，比如鍵盤按鍵按
下和彈起（分別對于KeyDown 和KeyUp 消息），卻需要通過它解釋，產生一個WM_CHAR
消息。DispatchMessage(&msg)負責把消息分發到消息結構體中對應的窗口，交由窗口過程
函數處理。GetMessage()在取得WM_QUIT 之前的返回值都為TRUE，也就是說只有獲取到
WM_QUIT 消息才返回FALSE，才能跳出消息循環。
2.4 消息的處理
取得的消息將交由窗口處理函數進行處理，對于每個窗口類Windows 為我們預備了一個
默認的窗口過程處理函數DefWindowProc()，這樣做的好處是，我們可以著眼于我們感興趣
的消息，把其他不感興趣的消息傳遞給默認窗口過程函數進行處理。每一個窗口類都有一個
窗口過程函數，此函數是一個回調函數，它是由Windows 操作系統負責調用的，而應用程
序本身不能調用它。以switch 語句開始，對于每條感興趣的消息都以一個case 引出。
LRESULT CALLBACK WndProc
(
HWND hwnd,
UINT message,
WPARAM wParam,
LPARAM lParam
)
{
…
switch(uMsgId)
{
case WM_TIMER：//對WM_TIMER 定時器消息的處理過程
return 0;
case WM_LBUTTONDOWN：//對鼠標左鍵單擊消息的處理過程
reurn 0;
. …
default:
return DefWindowProc(hwnd,uMsgId,wParam,lParam);
}
}
對于每條已經處理過的消息都必須返回0，否則消息將不停的重試下去；對于不感興趣
的消息，交給DefWindowProc()函數進行處理，并需要返回其處理值。
3. MFC 的消息映射
MFC 是Windows 下編程的微軟基礎類庫，封裝了大部分Windows API 和Windows 控件，
提供了一套消息映射和命令響應機制，方便了應用程序的開發。MFC 只是通過對Windows
消息映射的進行封裝，使得添加消息響應變得更為簡單，但深究起來，與Windows 消息機
制有一樣的底層實現。
3.1 MFC 消息映射的實現
在MFC 的框架結構下，“消息映射”是通過巧妙的宏定義，形成一張消息映射表格來進
行的。這樣一旦消息發生，Framework 就可以根據消息映射表格來進行消息映射和命令傳遞。
首先在需要進行消息處理的類的頭文件（.H）里，都會含有DECLARE_MESSAGE_MAP()
宏,聲明該類擁有消息映射表格。
然后在類應用程序文件（.CPP）實現這一表格
BEGIN_MESSAGE_MAP(CInheritClass, CBaseClass)
//{{AFX_MSG_MAP(CInheritClass)
ON_COMMAND(ID_EDIT_COPY,OnEditCopy)
………
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
這里主要進行消息映射的實現，把它和消息處理函數聯系在一起。其中出現三個宏，第
一個宏是BEGIN_MESSAGE_MAP 有兩個參數，分別是擁有消息表格的類，及其父類。第
二個宏是ON_COMMAND ， 指定命令消息的處理函數名稱。第三個是
END_MESSAGE_MAP()作為結尾符號。
DECLARE_MESSAGE_MAP 宏定義里包含了MFC 定義的兩個新的數據結構；
AFX_MSGMAP_ENTRY 和AFX_MSGMAP；其中AFX_MSGMAP_ENTRY 結構包含了
一個消息的所有相關信息,而AFX_MSGMAP 主要作用有兩個，一是用來得到基類的消息映
射入口地址。二是得到本身的消息映射入口地址。
實際上，MFC 把所有的消息一條條填入到AFX_MSGMAP_ENTRY 結構中去，形成一
個數組，該數組存放了所有的消息和與它們相關的參數。同時通過AFX_MSGMAP 能得到
該數組的首地址，同時得到基類的消息映射入口地址。當本身對該消息不響應的時候，就可
以上溯到基類的消息映射表尋找對應的消息響應。
MFC 通過鉤子函數_AfxCbtFilterHook()截獲消息，并在此函數中把窗口過程函數設置為
AfxWindProc,而原來的窗口過程函數被保存在成員變量m_pfnSuper 中。
在MFC 框架下，通過下面的步驟來對消息進行映射[7]。
1 函數AfxWndProc 接收Windows 操作系統發送的消息。
2 函數AfxWndProc 調用函數AfxCallWndProc 進行消息處理，這里一個進步是把對句柄的
操作轉換成對CWnd 對象的操作。
3 函數AfxCallWndProc 調用CWnd 類的方法WindowProc 進行消息處理。
4 WindowProc 調用OnWndMsg 進行正式的消息處理，即把消息派送到相關的方法中去處理。
5 如果OnWndMsg 方法沒有對消息進行處理的話，就調用DefWindowProc 對消息進行處理。
這就是MFC 對消息調用過程的巧妙封裝。
3.2 MFC 消息分類
1 命令消息(WM_COMMAND)
比如菜單項的選擇，工具欄按鈕點擊等發出該消息。所有派生自CCmdTarget 的類都有
能力接收WM_COMMAND 消息。
2 標準消息(WM_XXX)
比如窗口創建，窗口銷毀等。所有派生自CWnd 的類才有資格接收標準消息。
3 通告消息(WM_NOTIFY)
這是有控件向父窗口發送的消息，標示控件本身狀態的變化。比如下拉列表框選項的改
變CBN_SELCHANGE 和樹形控件的TVN_SELCHANGED 消息都是通告消息。
Window 9x 版及以后的新控件通告消息不再通過WM_COMMAND 傳送，而是通過
WM_NOTIFY 傳送， 但是老控件的通告消息， 比如CBN_SELCHANGE 還是通過
WM_COMMAND 消息發送。
4 自定義消息
利用MFC 編程，可以使用自定義消息。使用自定義消息需要遵循一定的步驟[2]并需要
自己編寫消息響應函數
4. MFC 消息的靈活運用
在此，我們給出一個示例程序，演示對MFC 消息的靈活運用，通過此例的剖析，將加
深我們對MFC 消息的理解。
4.1 示例功能描述
本示例程序將演示這樣一種效果：
對話框上有一個CTabCtrl 控件，一個CComboBox 控件，兩個按鈕Button1 和Button2。
CTabCtrl 控件有兩個標簽頁Tab1 和Tab2；CComboxBox 有兩個選項：選項1 和選項2；通
過按鈕（Button1 和Button2）單擊，分別發送CTabCtrl 控件的TCN_SELCHANGE 消息和
下拉列表框的CBN_SELCHANGE 消息，在各自的消息響應函數中只是簡單的對控件選項做
切換和給出提示信息。
單擊Button1 將選中標簽頁Tab1 和下拉列表框的選項1，并彈出提示信息；單擊Button2
將選中標簽頁Tab2 和下拉列表框的選項2，并彈出提示信息。
4.2 程序設計思路
TCN_SELCHANGE 消息和CBN_SELCHANGE 消息都屬于通告消息，此消息由子控件
發送給父窗口，在MSDN 中查詢發現TCN_SELCHANGE 消息是以WM_NOTIFY 消息的形
式發送，在MSDN 中查詢WM_NOTIFY 消息：
idCtrl = (int) wParam;
pnmh = (LPNMHDR) lParam;
也就是說，WPARAM 參數傳遞發送此消息的控件標識，LAPAM 參數一個指向NMHDR
結構體的指針。NMHDR 結構體定義如下：
typedef struct tagNMHDR
{
HWND hwndFrom;
UINT idFrom;
UINT code;
}
NMHDR; 其中hwndFrom 標識發送消息控件的句柄，idFrom 是發送消息控件的ID，code
則是消息碼，如果要發送TCN_SELCHANGE 消息，則以TCN_SELCHANGE 填充。
查詢MSDN 發現， 由CComboBox 控件發送的CBN_SELCHANGE 消息以
WM_COMMAND 消息發送，WPARAM 的高字節傳遞CComboBox 控件的ID，低字節發送
消息碼CBN_SELCHANGE，而LPARAM 則傳送發送此消息的控件句柄。
所以我們可以通過在按鈕控件的單擊響應函數里分別發送WM_NOTIFY 和
WM_COMMAND 消息來引起TCN_SELCHANGE 和CBN_SELCHANGE 消息響應函數的調
用，分別在兩控件消息響應函數中實現選項改變和消息提示即可，遵照這種思路，我們就可
以實現我們想要的功能。
4.3 程序實現步驟
啟動VC++6.0，新建基于對話框的應用程序MsgTest.
在對話框上添加1 個CTabCtrl 控件，一個CComboBox 控件，2 個按鈕Button1 和Button2；
給IDC_TAB1 和IDC_COMBO1 分別關聯控件成員變量m_tab1 和m_cb1；為兩按鈕分
別添加按鈕單擊響應函數。
在對話框的OnInitDlg()函數中為CTabCtrl 控件添加兩個標簽頁，Tab1 和Tab2；為
ComboBox 添加選項1 和2；代碼如下：
m_tab1.InsertItem(0,"Tab1");
m_tab1.InsertItem(1,"Tab2");
m_cb1.AddString("選項1");
m_cb1.AddString("選項2");
用ClassWizard 為CTabCtrl 添加消息響應TCN_SELCHANGE，為CComboBox 添加消息
響應CBN_SELCHANGE。在OnSelchangeTab1()函數中添加代碼
int nIndex=m_tab1.GetCurSel();
CString str;
str.Format("%d",nIndex+1);
MessageBox("Tab"+str+" selected!");
在OnSelchangeCombo1()函數中添加代碼：
int nIndex=m_cb1.GetCurSel();
CString str;
str.Format("%d",nIndex+1);
MessageBox("ComboBox 選項"+str+" selected!");
在按鈕1 的響應函數OnButton1()中添加代碼：
m_tab1.SetCurSel(0);
NMHDR nmhdr;
nmhdr.code=TCN_SELCHANGE;
nmhdr.hwndFrom=GetDlgItem(IDC_TAB1)->m_hWnd;
nmhdr.idFrom=IDC_TAB1;
SendMessage(WM_NOTIFY,(WPARAM)IDC_TAB1,(LPARAM)&nmhdr);
m_cb1.SetCurSel(0);
WPARAM wParam=0;
WPARAM lParam=0;
wParam=IDC_COMBO1;
wParam= wParam | (CBN_SELCHANGE<<16);
lParam=(WPARAM)(GetDlgItem(IDC_COMBO1)->m_hWnd);
SendMessage(WM_COMMAND, wParam, lParam);
在按鈕2 的響應函數OnButton2()中添加類似代碼，只需要把m_tab1.SetCurSel(0)和
m_cb1.SetCurSel(0)分別改成m_tab1.SetCurSel(1)和m_cb1.SetCurSel(1)。
通過SendMessage() 函數向控件的父窗口也就是對話框窗口發送相應的消息，
TCN_SELCHANGE 是以WM_NOTIFY 消息的形式發送，參數WPARAM 標識發送
TCN_SELCHANGE 消息的控件ID，LPARAM 是一個NMHDR 結構體的指針，此結構體的
成員code 標識發送什么通告消息，此處是TCN_SELCHANGE，hwndFrom 是發送消息的控
件句柄， 程序中用GetDlgItem()->m_hWdn 獲得， idFrom 是發送消息的控件ID 。
CBN_SELCHANGE 以WM_COMMAND 消息的形式發送，同樣的，通過查閱MSDN，可以
對此消息的兩個參數進行賦值，以保證消息的正確發送。
通過上面的5 個步驟，我們的程序就編寫完成了，單擊Button1，可以發現，CTabCtrl
切換到了Tab1 標簽頁，CComboBox 選擇了“選項1”，并彈出消息對話框。由此可見確實引
起了消息響應函數的調用，完成了預定的功能。
通過查閱MSDN，可以得到其他消息的發送和包裝形式，我們可以方便的加以利用，完
成更為復雜的功能，可以說，掌握了Windows 的消息機制，就掌握了Windows 編程的核心。
5. 總結
Windows 消息機制是Windows 編程的本質和核心，對Windows 消息機制的理解能提高
我們Windows 程序開發的能力。本文首先闡述Windows 的消息機制，然后講解了MFC 的
消息映射，消息分類，最后通過示例程序，講解如何借助MSDN，靈活運用消息編程，解
決實際問題。本文對Windows 下的程序開發具有一定的參考和借鑒意義。
/********************************
1.???????Windows 的歷史
中國人喜歡以史為鑒，而事實也確實是，如果你能知道一件事情的來龍去脈，往往可以更容易地理解事物為什么會表現為當前這樣的現狀。所以，我的介紹性開場白通常會以一段歷史開始。不過，我不會以精確到年月日的那種方式詳細講述，而是選取幾個對我們的編程生涯有重要影響的關鍵點。
Windows 是真正的圖形化界面操作系統的普及者，無論任何人，爭奪什么第一個實現的GUI、第一個商業化的GUI之類的虛名，都替代不了 Windows 的歷史功績，讓最普通的用戶能夠容易地操縱PC。
第一個聲名大噪的版本是Windows 3.0（也有人認為應該是它的更加健康強壯的弟弟Windows 3.1），從那個時候開始，我們就和本文中以下的幾個關鍵角色有了不盡的情緣：
[cpp]??view plain?copy
while(GetMessage(&msg, NULL,0, 0))
{
TranslateMessage(&msg);
DispatchMessage (&msg);
}
上面代碼中的這三個相關函數，會在后文中提到。
第二個大紅大紫的版本則非Windows 95莫屬。這個版本的主要變化在于，無論如何，它是一個大眾化的所謂32位系統了。之所以要加上“所謂的”三個字，是因為這個系統是個混血兒，在32位代碼中混雜有大量的從之前的Windows3.x上移植過來的16位代碼。
此時間稍后，另一支潛力股的關鍵進化過程結束，Windows NT 4.0隆重登場，這個分支的操作系統是全32位的，成為了 Windows 95 系列的掘墓者，也是我們現在所使用幾乎所有的 Windows 桌面系統（Windows2000/XP/2003/Vista/2008）的前輩。但是，這個版本由于對系統硬件的要求甚高（在當時），所以沒有引起普通用戶的廣泛關注。
下一個里程碑就是Windows 2000了，微軟實現了Windows9x/Me分支和Windows NT分支的合并。緊接著，Windows XP 現身。從有關消息方面來考察，Windows2000 做了微小的改進，在此之前，我們在很多情況下需要創建一個正常的、隱藏的、完整的窗口來處理消息，而 Windows 2000 引入了一種特殊類型的窗口用于此類需求。道理上來講，應該會減少一些資源占用。
此后經過五六年的時間，Windows Vista誕生。事實上，從 Windows2000 開始，Windows 家族的編程模型，尤其是對原生態代碼（native code）而言，已經基本沒有太大的變化。通常只是增加了新的API或者用戶控件，或者現有控件增加了新的功能或者風格。盡管 Windows Vista 中有很多的變化，但是對于我們今天要講到的主題，影響不大。最主要的一個影響，是消息的發送方和接收方之間有了等級限制，不像之前可以隨意互相進行消息傳遞，這是出于安全性的考慮。
2.???????Windows 的宏觀構造
從最原始的版本開始，有三個比較大的功能塊占據了Windows系統的絕大部分，這三個塊，就是赫赫有名的Kernel、GDI、User。從Windows 95起，另兩個在先前不太起眼的部分也迅速崛起，那就是大名鼎鼎的Registry和Shell。
這幾個大塊的分工是這樣的：Kernel，望文生義，負責內核部分，這是任何一個可以稱之為操作系統的東西的基石，主要職責有：內存管理、任務調度、外設管理等；GDI，則是對可以進行圖形化操縱的設備的操作接口，對外提供的主要功能是在設備上：提供坐標系統，繪制點、線、形狀，進行填充，文本繪制，管理畫筆、畫刷、字體等繪圖對象；User，則是前兩者的粘合劑，使系統能夠通過圖形化操作方式和使用者（也就是User）進行交互，把零散的GDI對象有機地組織起來，抽象為窗口，用以接受用戶的輸入，進行相應的運算（廣義上的，并不是局限于算數運算），并最終將結果呈現給用戶。當然，User 部分通常是指可以實現上述的功能的基礎構造，真正的實現部分需要大量的額外工作，這也是 Shell 部分的主要工作。而Registry，則是提供給用戶一種與物理存儲無關的統一的數據訪問方式。
很容易就可以看出，消息功能，這種被我們一直以窗口間通訊最為自然的方式所使用的機制，應該隸屬于 User 部分。
對于 Windows Mobile 系統來說，底層的實現上與桌面系統大相徑庭，例如，它本身并沒有kernel32.dll、gdi32.dll、user32.dll這幾個眾所周知的系統庫，而是有一個多合一的coredll.dll，而且內核被實現為一個更接近于正常進程的nk.exe進程，而不是桌面系統下的那個抽象的執行體。盡管如此，但是在邏輯上，我們依然可以將之與桌面系統同等看待。
3.???????Windows 的消息概念
在我們的通常認識上，消息事實就是一個數值。我們檢查一下消息相關的各個回調函數的原型就會發現，表示消息的那個參數的數據類型是 UINT，也就是無符號的整數類型。不過，我們通常也會發現，消息往往還附帶有兩個其他類型的數據，一個是 WPARAM 類型的，一個是 LPARAM 類型的，如果算上消息的目標窗口的句柄，那么，一個消息以及相關信息才能夠說是比較完整。為什么說是比較呢？看一下 MSG 這個結構的定義就會發現，其實還有另外兩個我們不太經常使用的數據，是與一條消息有關系的。MSG 的完整聲明如下：
[cpp]??view plain?copy
typedef struct {
HWND hwnd;
UINT message;
WPARAM wParam;
LPARAM lParam;
DWORD time;
POINT pt;
} MSG, *PMSG;
前四項正是我們已經提及過的，而后兩項，一個表示消息發生時的時間，一個表示此消息發生時的按屏幕坐標表示的鼠標光標的位置。
從這個結構也可以看出，我們經常所說的消息，更多是指代表了一個確定的消息的數值。
我們可能還會聽到有這樣的稱呼：命令消息、通知消息、反射消息等等。首先需要聲明的一點是，這并不是對 Windows 系統中的消息的科學分類，而是在某些特定場景下的通俗稱謂。命令消息，一般特指 WM_COMMAND 消息，此消息通常由控件或者菜單發出，表示用戶執行/發出了一個命令。通知消息，一般特指WM_NOTIFY 消息，此消息通常由公用控件（CommonControls）發出，表示一些事件發生了，需要處理。反射消息，一般用于對 Windows API 的封裝類或者類庫中。這是一類消息的總稱，它們的處理需要經過一種被稱為“反射”的機制。這一機制的具體方式下一節中會有描述。
Windows 的消息分類不好分（如果非要劃分的話，可以分為系統定義的消息和應用程序定義的消息），不過有一個區段劃分。從 0x0000 到 0x03FF，為系統定義的消息，常見的 WM_PAINT、WM_CREATE 等均在其中；從 0x0400 到 0x7FFF，專用于用戶自定義的消息，可以使用 WM_USER + x 的形式自行定義，其中WM_USER 的值就是 0x0400，x 取一個整數；從 0x8000 到 0xBFFF，從 Windows 95 開始，也用作用戶自定義的消息范圍，可以使用 WM_APP + x 的形式自行定義。根據微軟的建議，WM_APP類消息用于程序之間的消息通信，而 WM_USER 類消息則最好用于某個特定的窗口類。微軟自己遵循這一慣例，所以，公用控件的消息，如 TVM_DELETEITEM，基本都是 WM_USER 類屬。從 0xC000 開始，到 0xFFFF，這個區段的消息值保留給 RegisterWindowMessage 這個 API，此 API 可以接受一個字符串，把它變換成一個唯一的消息值。在桌面系統上，最常見的源字符串，可能就是“TaskbarCreated”了，由它對應的消息會發送到所有的頂級窗口，通知任務欄剛剛被創建（可能是由于資源管理崩潰后重新啟動導致的）。
由上也可以看出，Windows 的消息值是一個 16 位的數字，這是 16 系統時代留給我們的痕跡。另外的一個痕跡是WPARAM 和 LPARAM 這兩個數據類型，在 16 位時代，WPARAM 是 16 位的，其名字的意思是 wordparameter，LPARAM 是 32 位的，其名字的意思是 longparameter。
4.???????Windows 的消息機制
4.1.???????消息隊列
說到消息機制，可能連最初級的 Windows 程序員都會對消息隊列（MessageQueue）這個名詞耳熟（不過不見得能詳）。對于這樣一個基本概念，Windows 操作系統提供的針對消息隊列的API 卻少的可憐（GetQueueStatus、GetInputState、GetMessageExtraInfo、SetMessageExtraInfo），而且，這些 API 的出鏡率也相當的低，甚至有不少經驗豐富的程序員也從來沒有使用過它們。在 Windows Mobile 上，這些 API 干脆付諸闕如，不過有一個同樣極少使用的GetMessageQueueReadyTimeStamp 函數在充門面。
這一切，都歸功于在 API 層極好的封裝性，減少了開始接觸這個平臺時需要了解的概念。但是，對于我們這樣既想知其然，又想知其所以然的群體，還是有必要對消息隊列有充分的了解。
4.1.1.??????系統消息隊列
這是一個系統唯一的隊列，輸入設備（鍵盤、鼠標或者其他）的驅動程序會把用戶的操作輸入轉化成消息放置于系統隊列中，然后系統會把此消息轉到目標窗口所在線程的消息隊列中等待處理。
4.1.2.??????線程消息隊列（應用程序消息隊列）
應用程序消息隊列這個名稱是歷史遺留，在 32 位（以及之后的 64 位）系統中，正確的名稱應該是線程消息隊列。每一個GUI線程都會維護這樣一個線程消息隊列。（這個隊列只有在線程調用 User 或者 GDI 函數時才會創建，默認并不創建）。然后線程消息隊列中的消息會被本線程的消息循環（有時也被稱為消息泵）派送到相應的窗口過程（也叫窗口回調函數）處理。
4.2.???????消息的生命期
4.2.1.??????消息的產生
消息產生的源頭有兩個，一個是系統，一個是應用程序。系統產生的消息又可以大致分為兩類，一類是由輸入設備導致的，例如 WM_MOUSEMOVE，一類是User部分（或者是系統內的其他部分通過User部分）為了實現自身的正常行為或者管理功能而主動生成的，如 WM_WINDOWPOSCHANGED。
產生的方式也有兩種，一種稱為發送（Send），另一種稱為投遞（Post，也有譯作張貼的），對應于大家極為熟悉的兩個 API，SendMessage 和 PostMessage。系統產生的消息，雖然我們看不到代碼，不過我們還是可以粗略地劃撥一下，基本上所有的輸入類消息，都是以投遞的方式抵達應用的，而其他的消息，則大部分是采取了發送方式。
至于應用程序，可以隨意選用適合自己的消息產生方式。
4.2.2.??????消息的處理
在絕大部分情況下，消息總是有一個目標窗口的，因此，消息也絕大部分是被某個窗口所處理的。處理消息的地方，就是這個窗口的回調函數。
窗口的回調函數，之所以被稱作“回調”，就是因為這個函數一般并不是由用戶（程序員）主動調用它的，而是系統認為在恰當的時候對它進行調用。那么，這個“恰當的時候”是什么時候呢？根據消息產生的方式，“恰當的時候”也有兩個時機。
第一個時機是，DispatchMessage 函數被調用時，另一個時機是SendMessage 函數被調用時。
我們正常情況下以系統處理對一個頂級窗口的關閉按鈕的鼠標左鍵點擊事件為例來說明。
這個點擊事件完成的標志性消息是 WM_NCLBUTTONUP，表示在一個窗口的非客戶區的鼠標左鍵釋放動作，另外，這個鼠標消息的其他數據中會表明，發生這個動作的位置是在關閉按鈕上（HTCLOSE）。這是一個鼠標輸入事件，從前文可以知道，它會被系統投遞到消息隊列中。
于是，在消息循環中GetMessage 的某次執行結束后，這個消息被取到了 MSG 結構里。從文章開頭的消息循環代碼可知，這個消息接下來會被 TranslateMessage 函數做必要的（事實上是“可能的”）翻譯，然后交給 DispatchMessage 來全權處理。
DispatchMessage 拿到了 MSG 結構，開始自己的一套辦事流程。
首先，檢查消息指定的目標窗口句柄。看系統內（實際上是本線程內）是不是確實存在這樣一個窗口，如果沒有，那說明這個消息已經不會有需要對它負責的人選了，那么這個消息就會被丟棄。
如果有，它就會直接調用目標窗口的回調函數。終于看到，我們寫的回調函數出場了，這就是“恰當的時機”之一。當然，為了敘述清晰，此處省略了系統做的一些其他處理。
這樣，對于系統來說，一條投遞消息就處理完成，轉而繼續 GetMessage。
不過對于我們上面的例子，事情還沒有完。
我們都清楚，對于 WM_NCLBUTTONUP 這樣一條消息，通常我們是無暇去做額外處理的（正事還忙不過來呢……）。所以，我們一般都會把它扔到那個著名的垃圾堆里，沒錯，DefWindowProc。盡管如此，我們還是可以看出，DefWindowProc其實已經成了我們的回調函數的一個組成部分，唯一的差別在，這個函數不是我們自己寫的而已。
DefWindowProc 對這個消息的處理也是相當輕松，它基本上沒有做什么實質性的事情，而是生成了另外一個消息，WM_SYSCOMMAND，同時在 wParam 里指定為 SC_CLOSE。這一次，消息沒有被投遞到消息隊列里，而是直接 Send 出來的。
于是，SendMessage 的艱難歷程開始。
第一步，SendMessage 的方向和DispatchMessage 幾乎一模一樣，檢查句柄。
第二步，事情就來了，它需要檢查目標窗口和自己在不在一個線程內。如果在，那就比較好辦，按照 DispatchMessage 趟出來的老路走：調用目標窗口的回調函數。這，就是“恰當的時機”之二。
可是要是不在一個線程內，那就麻煩了。道理很簡單，別的線程有自己的運行軌跡，沒有辦法去讓它立即就來處理這個消息。
現在，SendMessage該怎么處理手里的這個燙手山芋呢？（作者注：寫到此處時，很有寫上“欲知后事如何，且聽下回分解”的沖動）
微軟的架構師做了個非常聰明的選擇：不干涉其他線程的內政。我不會生拉硬拽讓你來處理我的消息，我會把消息投遞給你（這個投遞是內部操作，從外面看，這條消息應該一直被認為是發送過去的），然后—— 我等著。
這下，球踢到了目標線程那邊。目標線程一點也不含糊，既然消息來到了我的隊列里，那我的 GetMessage 會按照既定的流程走，不過，和上文WM_NCLBUTTONUP 的經歷有所不同。鑒于這條消息是外來客，而且是Send 方式，于是它以優先于線程內部的其他消息進行處理（畢竟友邦在等著啊），處理完畢之后，把結果返回給消息的源線程。可以參見下文中對 GetMessage 函數的敘述。
在我們的現在討論的這個例子里，由于 SendMessage(WM_SYSCOMMAND) 是屬于本線程內的，所以就會遞歸調用回窗口的回調函數里。此后的處理，還是另外的幾個消息被衍生出來，如 WM_CLOSE 和 WM_DESTROY。這個例子僅僅出于概念性的展示，而不是完全精確可靠的，而且，在 Windows Mobile 上，干脆就沒有非客戶區的概念。
這就是系統內所有消息的處理方式。
不過稍等，PostThreadMessage 投遞到消息隊列里的消息怎么辦？答案是：你自己看著辦。最好的處理位置，就是在消息循環中的TranslateMessage 調用之前。
另外一個需要稍做注解的問題是消息的返回值問題，這個問題有些微妙。對于大多數的消息，返回值都沒有什么意義。對于另外的一些消息，返回值意義重大。我相信有很多人對 WM_ERASEBKGND 消息的返回值會有印象，該消息的返回值直接影響到系統是不是要進行缺省的繪制窗口背景操作。所以，處理完一條消息究竟應該返回什么，查一下文檔會更穩妥一些。
這才算是功德圓滿了。
4.2.3.??????消息的優先級
上一節中其實已經暗示了這一點，來自于其他線程的發送的消息優先級會高一點點。
不過還需要注意，還有那么幾個優先級比正常的消息低一點點的。它們是：WM_PAINT、WM_TIMER、WM_QUIT。只有在隊列中沒有其他消息的時候，這幾個消息才會被處理，多個 WM_PAINT 消息還會被合并以提高效率（內幕揭示：WM_PAINT 其實也是一個標志位，所以看上去是被“合并了”）。
其他所有消息則以先進先出（FIFO）的方式被處理。
4.2.4.??????沒有處理的消息呢？
有人會問出這個問題的。事實上，這差不多就是一個偽命題，基本不存在沒有處理的消息。從 4.2.2 節的敘述也可以看出，消息總會流到某一個處理分支里去。
那么，我本人傾向于提問者在問這樣一個問題：如果窗口回調函數沒有處理某個消息，那這個消息最終怎么樣了？其實這還是取決于回調函數實現者的意志。如果你只是簡單地返回，那事實上也是進行了處理，只不過，處理的方式是“什么都沒做”而已；如果你把消息傳遞給 DefWindowProc，那么它會處理自己感興趣的若干消息，對于別的消息，它也一概不管，直接返回。
4.3.???????消息死鎖
假設有線程A和B， 現在有以下步驟：
1) 線程A SendMessage 給線程B，A 等待消息在線程B 中處理后返回
2) 線程 B 收到了線程A 發來的消息，并進行處理，在處理過程中，B 也向線程 A SendMessage，然后等待從A 返回。
此時線程A正等待從線程B返回，無法處理B發來的消息，從而導致了線程A 和B相互等待，形成死鎖。
以此類推，多個線程也可以形成環形死鎖。
可以使用 SendNotifyMessage 或 SendMessageTimeout來避免出現此類死鎖。
（作者注：對兩個線程互相 SendMessage 曾經專門寫程序進行過驗證，結果卻沒有死鎖，不知道是不是新一些的 Windows 系統作了特殊的處理。請大家自行驗證。）
4.4.???????模態（Modal）
這個詞匯曾給我帶來極大的困惑，我曾經做過不少的努力，想弄清楚為什么當初系統的構建者使用“模態”這個詞匯來表達這樣一種情景，但是最后失敗了。我不得不接受這個詞，并運用它。直到數天前，我找到了一個對模態的簡要介紹，如果有興趣，各位可以自己去看：http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=320。（我曾做過的另外一個努力是想知道為什么Handle會被翻譯為“句柄”，或者，是誰首先這樣翻譯的，迄今無解）。Windows 中的模態有好幾個場景，比較典型的有：
顯示了一個對話框
顯示出一個菜單
操作滾動條
移動窗口
改變窗口大小
把我的體會歸納起來，那就是：如果進入了一個模態場景，那么，除了這個模態本身的明確目標，其余操作被一概禁止。概念上可以理解為，模態，是一種獨占模式、一種強制模式，一種霸道模式。
在 Windows 里，模態的實現其實很簡單，只不過就是包含了自己的消息循環而已，說穿了毫無懸念可言，但是如果不明白這個內幕的話，就會覺得很神秘。那么，根據此結論，我們就可以做一些有趣（或者有意義）的事情了，看一下以下代碼，預測一下 TestModal 的執行結果：
[cpp]??view plain?copy
void CALLBACK RequestQuit(HWNDhwnd, UINT uMsg, UINT idEvent, DWORD dwTime);
void TestModal()
{
UINT uTimerId =SetTimer(NULL, 66, 1000, RequestQuit);
MessageBox(NULL, NULL, NULL,MB_OK);
KillTimer(NULL, uTimerId);
}
void CALLBACK RequestQuit(HWND hwnd, UINT uMsg, UINT idEvent, DWORD dwTime)
{
PostMessage(NULL, WM_QUIT,0, 0);
}
答案見本大節末尾。
需要提醒的是，模態是用戶界面里相當重要而普遍的一個概念，不僅存在于 Windows 環境下，也存在于其他的用戶界面系統中，例如 Symbian。
4.5.???????與消息處理有關的鉤子（Hook）
很多人都或多或少地聽說過或者接觸過鉤子。鉤子在處理事務的正常流程之外，額外給予了我們一種監聽或者控制的方式（注意：在 Windows Mobile 系統下，鉤子并不被正式支持）。
（TODO: 細化，不過由于這個內容針對桌面系統更多，所以暫時可以略過）
4.6.???????所謂的反射（Reflection）
上文也已經提到，反射通常會在對 Windows API 的封裝類或者類庫中出現，這是由于Windows SDK 的 API 是以 C 的風格暴露給使用者的，與 C++ 語言的主要用類編程的風格有一些需要嚙合的地方。
舉例來說，一個Button，在 SDK 中是一個已經定型的控件，基本上實現了自包容，要擴展它的功能的話（例如，繪制不同的外觀），系統把接口（廣義上的接口，即一種交互上的契約）制定為發給 Button 的屬主（通常就是父窗口）的兩條消息（WM_MEASUREITEM 和 WM_DRAWITEM）。其道理在于，使用 Button 控件的父窗口，往往是用戶自己實現的，處理起來更方便，而不需要對 Button 自身做什么手腳。
但是，這種交互方式在 C++ 的世界里是相當忌諱的。C++ 的自包容單位是對象，那么一個 Button 對象的封裝類，假定是CButton，不能自己處理自己的繪制問題，這是不太符合法則的（盡管不是不可以）。
為了消除這一不和諧音，就有人提出了反射機制。其核心就在于，對于本該子控件自己處理的事件所對應的消息（如前面的 WM_DRAWITEM），父窗口即使收到，也不進行直接處理，而是把這個消息重新發回給子控件本身。
這樣帶來一個問題，當 Button 收到一個 WM_DRAWITEM消息時，弄不清楚究竟是自己的子窗口發來的（雖說往 Button 上建立子窗口不常見，但不是不可以），還是父窗口把原本是自己的消息反射回來了。所以，最后微軟給出一個解決辦法，就是反射消息的時候，把消息的值上加一個固定的附加值，這個值就是 OCM__BASE。盡管最初只是微軟自己在這樣做，這個值也完全可以各取各的，但是后來別的類/類庫的編制者幾乎都無一例外地和微軟保持了一致。
當控件收到消息之后，先把這個附加值減掉，就可以知道是哪一條消息被反射回來了，然后再作相應的處理。
4.4節小測試的答案：一個消息框顯示大概 1 秒鐘的時間，然后自動消失。有的人根據這一表現，寫出了自己的超時候自動關閉的消息框。如果各位有興趣，可以自己嘗試也實現一下。（提示：需要考慮一下用戶先于定時器觸發就手動關閉了消息框的情況）
5.???????Windows 的消息本質
一個特殊的事件同步機制，使用多種常規線程間同步機制實現。
6.???????Windows 的消息操縱
注意：以下討論中用淺綠色標注的函數，表示在 WindowsMobile 平臺上是沒有的。
[cpp]??view plain?copy
SendMessage
PostMessage
在使用消息的過程中，這兩個函數的使用率是最高的。初學者有時會搞不清楚這兩個發送消息的函數的使用場景，容易誤用。所以放在這里一起說。其實上面已經對 SendMessage 做了很多的介紹，所以在這兒的重點會放在 PostMessage 上。相較 SendMessage而言，PostMessage 的工作要輕松許多，只要找到知道那個的窗口句柄所在的線程，把消息放到該線程的消息隊列里就可以了，完全不理會這條消息最終的命運，是不是被正確處理了。
這一點，從 PostMessage 和 SendMessage 的返回值的不同也有體現。PostMessage 函數的返回值是 BOOL 類型，體現的是投遞操作是否成功。投遞操作是有可能失敗的，盡管我們不愿意同時也確實很少看到。例如，目標線程的消息隊列已經滿（在 16 位時代出現概率較高），或者更糟糕，目標線程根本就沒有消息隊列。
當然，PostMessage 也要檢查窗口句柄的合法性，不過和SendMessage 不同的一點是，它允許窗口句柄是 NULL。在此情況下，對它的調用就等價于調用 PostThreadMessage 向自身所在線程投遞一條消息。
從上面的描述可以很容易地看出，PostMessage 和 SendMessage 的本質區別在于前者發出的消息是異步處理的，而后者發出的消息是同步處理的。理解這一點非常重要。
從上面的這個結果推演，還可以得到另外一個有時會很有用的推論。在本線程之內，如果你在處理某個窗口消息的時候，希望在處理之后開展另一項以此消息為前提的工作，那么可以向本窗口 Post 一條消息，來作為該后續工作的觸發機制。
?
[cpp]??view plain?copy
檢查線程的消息隊列，如果有消息就取出該消息到一個傳入的 MSG 結構中并返回，沒有消息，就等待。等待時線程處于休眠狀態，CPU被分配給系統內的其他線程使用。
需要注意的是，由其它線程 Send 過來的消息，會在這里就地處理（即調用相應的窗口回調函數），而不會返回給調用者。
[cpp]??view plain?copy
這個消息的來龍去脈在上文中已經有較為詳細的敘述，故此略去。
[cpp]??view plain?copy
這個函數在本質上與消息機制的關系不大，絕大多數的消息循環中都出現它的身影是因為絕大多數的程序員都不知道這個函數真正是干什么的，僅僅是出于慣例或者初學時教科書上給出的范例。這個函數的作用主要和輸入有關，它會把 WM_KEYDOWN 和 WM_KEYUP 這樣的消息恰當地、適時地翻譯出新的消息來，如 WM_CHAR。如果你確信某個線程根本不會有用戶輸入方面的需求，基本上可以安全地將之從循環中移除。
可以和它相提并論的就是列出的 TranslateAccelerator 函數，這個函數會把用戶輸入根據指定的加速鍵（Accelerator）表翻譯為適當的命令消息。
[cpp]??view plain?copy
窺探線程的消息隊列。無論隊列中有沒有消息，這個函數都立即返回。它的參數列表與 GetMessage 基本一致，只是多了一個標志參數。這個標志參數指定了如果隊列中如果有消息的話，PeekMessage 的行為。如果該標志中含有PM_REMOVE，則 PeekMessage 會把新消息返回到 MSG 結構中，正如 GetMessage 的行為那樣。如果標志中指定了 PM_NOREMOVE，則不會取出任何消息。
[cpp]??view plain?copy
這個函數的作用是等待一條消息的到來。等待期間線程處于休眠狀態，一旦有新消息到來，則立即返回。
了解了 PeekMessage 和 WaitMessage 之后，理論上，我們可以寫出自己的 GetMessage 了。
[cpp]??view plain?copy
這個函數很有意思，它的行為屬于看人下菜碟型。如果目標線程就是自身所處線程，那么它就是SendMessage；而一旦發現目標線程是其他線程，那它就類似于PostMessage，不等待目標窗口處理完成。不過，僅僅是類似，因為它發出的消息仍然會被目標線程認為是 Send 過來的。
SendMessageTimeout
這個函數可以說是 SendMessage 函數家族（相對PostMessage 而言）之中最強大的函數。它在標準的SendMessage 函數的功能前提下，加入了許多額外的控制選項以及一個超時設定。例如，它可以指定，如果發現目標窗口已經失去響應的話，那么就立即返回；也可以指定如果目標窗口的響應時間超過了指定的超時時限的話也返回，而不是無限等待下去。而且我們知道，SendMessage 是會固執地等待下去的。（內幕揭示：SendMessage 其實就是對 SendMessageTimeout的一個淺封裝）
[cpp]??view plain?copy
與 SendMessageTimeout 不同，這個函數在另外一個方向上對標準的 SendMessage 進行了擴展。它的行為與SendNotifyMessage 類似，只不過允許在對方處理完消息之后，指定一個本線程內的后續處理函數。仔細觀察可以發現，SendNotifyMessage 其實是本函數的一個特例。
對這個函數的使用場景較少，實際上，作者幾乎從來沒有見到必須使用它的情況。網上有一些對此函數的討論和測試代碼，但很少有實用價值。（恐怕這也是 Windows Mobile 沒有實現此函數的原因之一。）
[cpp]??view plain?copy
這個函數的名字具有迷惑性。事實上，它本身并不會投遞任何消息，而是偷偷在系統內部置了一個標志，當調用 GetMessage 時會檢測此標志位。若此標志位被置位，而且隊列中已經沒有別的符合條件的投遞消息，則 GetMessage 返回 FALSE，用以終止消息循環。
不過，有人會有這樣的疑惑。我們知道，PostMessage 當窗口句柄為 NULL 的時候，就相當于 PostThreadMessage(GetCurrentThreadId(), …)，那么，為什么不用 PostMessage(NULL, WM_QUIT, 0, 0)，而要引入這么一個單獨的 API 呢？有的人給出的原因是，這個 API 出現在 Windows 的 16 位時代，當時還沒有線程的概念。這個答案仔細推敲的話，其實似是而非，因為完全可以把進程的執行看作是一個線程。真正的原因，可能從前文能得到一些思考線索，尤其注意“隊列中已經沒有別的符合條件的投遞消息”這個敘述。
[cpp]??view plain?copy
跨線程投遞消息。我們知道，消息隊列是屬于線程的，所以，可以不指定目標窗口而只指定目標線程就投遞消息。投遞到目標線程的消息通常會被 GetMessage取出，但是，由于沒有指定目標窗口，所以不會被派發到任何一個窗口回調函數中。
請注意上文中的通常二字。這是因為在一般的情況下，我們是按照 GetMessage(&msg, NULL, 0, 0) 這樣的形式對 GetMessage 進行調用的，但是，第二個參數是一個窗口句柄，如果指定了一個合法的窗口句柄，那么 GetMessage 就只會取出與該窗口有關的投遞消息。如果這樣的調用放在線程的主消息循環中，就可能會造成消息積壓（這和你在本線程中究竟創建了多少個窗口有關）。所幸的是，迄今我還沒有見到過有誰這樣使用 GetMessage。
[cpp]??view plain?copy
我們一般所接觸到的消息都是發送給窗口的，其實， 消息的接收者可以是多種多樣的，它可以是應用程序（application）、可安裝驅動程序（installable driver）、網絡驅動程序（networkdriver）、系統級設備驅動程序（system-leveldevice driver）等，用 BroadcastSystemMessage這個API可以對以上系統組件發送消息。
[cpp]??view plain?copy
這個函數用于在處理某條消息時，檢查消息是不是來自于其他線程的發送操作。它的使用場景也極其有限，除非你確實計劃限制某些消息的來源和產生方式。
[cpp]??view plain?copy
這個函數在 MSDN 中的解釋非常簡單，只有寥寥數語，幾乎到了模糊不清的地步。從示例代碼段來推測，其作用大概是：消息的接收線程（目標線程）在處理過程中可以通過調用此函數使得消息的發送線程（源線程）結束等待狀態繼續執行。
根據微軟的文檔，其官方建議是：在處理每個有可能來自于其他線程的消息的時候，如果某一步驟的處理會調用到導致線程移交控制的函數（原文如此：any function that causes the thread to yield control），都應該先調用InSendMessage 類屬的函數進行判斷，如果返回TRUE，則要立即使用 ReplyMessage 答復消息的源線程。
“會導致線程移交控制的函數”，MSDN 給出的例子是 DialogBox，這使得我做出自己的推測，這樣的函數，至少包括會導致進入某種模態場景的函數。
至于“有可能來自于其他線程的消息”，在 Windows 世界里的現實狀況是，幾乎任何一個消息都會來自于其他線程。
我多年以來的觀察可以斷定，現實中有無數沒有進行以上流程判斷的代碼都在運行，而且也幾乎沒有暴露出什么嚴重的不良后果。這使得我有理由猜測，微軟也許已經把對此情況的處理隱含到了系統內部。更何況，Windows Mobile 中根本就沒有ReplyMessage 這個 API。
[cpp]??view plain?copy
GetMessagePos
GetMessageTime
這兩個函數用于訪問當前處理的消息的另外兩個信息，對應于 MSG 結構里的相應域。它們存在的原因是因為窗口回調/消息處理函數一般都不會傳遞這兩個數據。
[cpp]??view plain?copy
這是一個在講到消息相關的內容時，十有八九會被人遺忘的 API。它屬于傳統的 ITC、IPC 和 Windows 特有的消息機制的交叉地帶。不過，在 Windows 平臺上，如果還沒有了解并掌握這個函數，那一定不能稱其為專家。
這個函數揭示了以下平時不太為人所注意的細節：
1、? 消息和內核對象，有千絲萬縷的聯系
2、? 消息和內核對象可以按照相似的方式去處理
如果說，SendMessageTimeout 是 Windows 平臺下最強大的發送消息的機制，那么，MsgWaitForMultipleObjects[Ex] 就是最強大等待機制，它是 WaitMessage 和 WaitFor… 函數族的集大成者。根據我們上面使用 WaitMessage 和 PeekMessage 結合使用可以取代 GetMessage 的論斷，我們也可以這樣說，MsgWaitForMultipleObjects[Ex]是最強大的消息循環發動機。
仔細描述此函數會超出單純的消息機制范疇，所以把深入學習它的工作遺留給各位自己去實踐。
7.???????Windows 的消息辨析
7.1.???????SendMessage和PostMessage的區別
請考慮有面試考官問及此問題時你如何組織回答。J
7.2.???????SendMessage發送的消息不進入消息隊列嗎
提示：請考慮跨線程的情況。
這個說法不完全正確。當SendMessage發送的消息跨越線程邊界時，消息其實被加入到了目標線程的消息隊列里。不過，在線程隊列里，別的線程Send過來的消息會被優先處理。
7.3.???????PostMessage(WM_QUIT)和PostQuitMessage()的區別，可能會產生怎樣的差異化執行效果
提示：請考慮發生以上某個調用時，消息隊列里不為空的情況。
7.4.???????文章開頭的經典消息循環正確么？
提示：請注意 GetMessage 的返回值。
曾經有很長一段時間，連微軟的例子也這樣寫。但是，這樣寫其實是不對的。原因很簡單，GetMessage不僅僅是取道消息返回 TRUE，取不到（遇到WM_QUIT 消息）返回FALSE這么單純，它還會出錯。出錯時返回 -1。這就了能使得經典循環在GetMessage發生錯誤時變成死循環。微軟的建議是，當GetMessage返回 -1 時，跳出循環，結束程序。
注：本文乃是數年前的培訓講義，文中有某處不完整，迄今未補，讀者自察之。
Windows Features
>桌面窗口
? ? GetDesktopWindow:獲取桌面窗口句柄
? ? SystemParameter(wAction=SPI_SETDESKWALLPAPER)：設置桌面壁紙
>窗體結構
>客戶區和非客戶區
? ? 客戶區：應用程序中可以直接輸出的區域
? ? 非客戶區：應用程序中的特殊區域（保護標題欄、菜單欄、系統按鈕等）
>窗口創建消息：在這些消息中處理程序初始化的任務
? ? WM_NCCREATE:創建非客戶區消息
? ? WM_CREATE:創建客戶區消息
? ? WM_PARENTNOTIFY:創建子窗口后系統發送給父窗口
>?窗口類型
? ? 1.OverlappedWindows：
? ? ? ? 是一種頂層窗口
? ? ? ? 有標題欄、邊框、客戶區(WS_OVERLAPPED)，可選：窗口菜單、最小化和最大化按鈕、滾動條(WS_OVERLAPPEDWINDOW)
? ? ? ? 通常作為程序的主窗口
? ? ? ?
? ? 2.Pop-UpWindows:彈出窗口
? ? ? ? 是一種特殊的Overlapped窗口
? ? ? ? 經常用來彈出對話框、消息窗口和臨時窗口
? ? ? ? 使用WS_POPUP樣式創建窗口
? ??
? ? 3.Child Windows:子窗口
? ? ? ? WS_CHILD樣式
? ? ? ? 局限于父窗口的顯示區，必須為其指定一個父窗口
? ? ? ? 通常用來切分父窗口
? ? ? ? 子窗口顯示默認是在父窗口的左上角，如果比父窗口大，則進行裁剪
? ? ? ? 父窗口的消息影響其子窗口:?
? ? ? ? ? ? Destroyed:子窗口先銷毀?
? ? ? ? ? ? Hidden:子窗口先隱藏
? ? ? ? ? ? Moved:隨著父窗口移動，移動后得自繪
? ? ? ? ? ? Show:父窗口先顯示
? ? ? ? 裁剪：WS_CLIPCHILDREN樣式使父窗口不能在子窗口之上繪制
? ? ? ? 和父窗口關系：
? ? ? ? ? ? SetParent：指定一個父窗口，參數為NULL時，顯示在桌面上，可以自由拖動
? ? ? ? ? ? GetParent：獲得父窗口的句柄
? ? ? ? ? ? IsChild：判斷一個窗口是不是另一個窗口的子窗口
? ? ? ? ? ? EnumChildWindow：枚舉子窗口
? ? ? ? ? ? 子窗口和父窗口的類型可以不一樣
? ? 消息：
? ? ? ? ? ? 子窗口的消息直接發送給子窗口，如被禁止，則發送到父窗口
? ? ? ? ? ? EnableWindow：禁止或啟用一個子窗口
? ? ? ? ? ??
? ? ?層疊窗口：WS_EX_LAYERED
? ? 消息窗口：
? ? ? ? 不可見、沒有z自序，不能被枚舉，不能收到廣播消息
? ? ? ? 使用HWND_MESSAGE句柄
? ? ? ? 使用FindWindowEx并傳入HWND_MEAAGE查找窗口
? ? ? ? ? ??
??窗口關系
>前臺窗口與后臺窗口
? ? 和用戶交互的窗口叫做前臺窗口，創建的線程叫做前臺線程
? ? 其他線程創建的窗口叫做后臺窗口，其他線程叫做后臺線程
? ? 前臺窗口線程的優先級(9)高于其他線程的(7)
? ? 設置前臺窗口：點擊、Alt+Tab、Alt+Esc
? ? 獲取前臺窗口句柄：GetForegroundWindow()
? ? 設置前臺窗口：SetForegroundWindow()，設置的進程需要滿足特定的條件
>Owned窗口
? ? 窗口在其擁有者窗口之上(Z order)
? ? 擁有者窗口銷毀時被擁有者窗口也自動銷毀
? ? 擁有者窗口最小化時被擁有者窗口隱藏
? ? 只有Overlapped和popup窗口可以稱為擁有者窗口，子窗口不能稱為擁有者窗口
? ? 通過GetWindow及參數GW_OWNER獲取窗口的擁有者窗口
>Z-Order
? ? 頂層窗口在所有其它非頂層窗口之上
? ? BringWindowToTop、SetWindowPos、DeferWindowPos設置窗口在Z序的位置
窗口狀態
>Aactive Windows:當前用戶正在使用的窗口
? ? SetActiveWindows：切換激活窗口（本進程內？）
? ? SetWindowsPos、DeferWindowPos、SetWindowPlacement
? ? GetActiveWindow
? ? WM_ACTIVATEAPP：發送激活窗口切換時系統發送給兩個窗口
>Disable Windows：
? ? Disable窗口不能收到鼠標和鍵盤消息
? ? EnableWindow：禁止或啟用一個窗口
? ? IsWindowEnabled：判斷一個窗口是否可用
? ? 子窗口被disable的時候，父窗口可以接收子窗口的鼠標消息
>可見性
? ? 如果一個窗口被隱藏等同于失效
? ? IsWindowVisible:判斷一個窗口是否可見
>CloseWindow:最小化窗口
? ? SetWindowPlacement與ShowWindows功能類似，還可以改變最小化、最大化和恢復時默認的位置
? ? WM_QUERYOPEN:最大化或恢復窗口時，系統給窗口發送這個命令
? ? WM_GETMINMAXINOF:后去窗口的默認大小信息
Windows大小和位置
>WM_GETMINMAXINFO:獲取窗口大小拖動時最大尺寸和最小尺寸
? ? WS_THICKFREAME：容許一個窗口大小被拖動
>WM_SYSCOMMAND:用戶點擊窗口菜單時由系統發送
? ? SC_CLOSE：關閉窗口，發送WM_CLOSE消息到窗口
? ? SC_MAXIMIZE：最大化窗口
? ? SC_MINIMIZE：最小化窗口
? ? SC_MOVE：移動窗口
? ? SC_RESTORE：恢復最大化或最小化之前的大小
? ? SC_SIZE：改變窗口大小
>改變大小或位置：
? ? SetWindowPlacement：設置窗口最大化、最小化，恢復的大小和位置，以及顯示狀態
? ? MoveWindow和SetWindowPos：設置窗口位置
? ? XXXDeferWindowPos：同時設置窗口的大小、位置，Z序和顯示狀態
? ? GetWindowRect:獲取窗口矩形信息，都是相對于桌面的位置
? ? ScreenToClient和MapWindowPoints：進行坐標轉化
? ? GetClientRect：獲取客戶區的矩形，相對與自身的
? ? TileWindows和?CascadeWindows: 將左右最大化窗口還原? ??
? ? ??WM_WINDOWPOSCHANGING：窗口大小和位置改變之后會收到此消息
? ? WM_NCCALSIZE：窗口創建時和大小改變時會收到此消息
>AnimateWindow：特殊顯示或隱藏窗口
窗口銷毀
>DestroyWindow：銷毀窗口
? ?給自己和所有子窗口發送WM_DESTROY消息
>WM_CLOSE:在銷毀窗口前，提供給用戶一個確認的機會
>WM_DESTROY:給應用程序一次清理資源的機會
>PostQuitMessage:應用程序清理完資源時調用，退出主消息循環
>UpdateWindow：發送WM_PAINT消息
?
總結
以上是生活随笔為你收集整理的windows消息机制详解-3的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： vue 组件间传值、兄弟组件 、bus方
- 下一篇： Jackson使用：String 与对象