深度解析VC中的訊息傳遞機制（下）

深度解析VC中的訊息傳遞機制（下）
2007-04-14 09:01:08  www.hackbase.com  來源：網際網路
訊息的接收

　　 訊息的接收主要有３個函式：GetMessage、PeekMessage、W
訊息的接收

　　 訊息的接收主要有３個函式：GetMessage、PeekMessage、WaitMessage。

　　　 GetMessage原型如下：BOOL GetMessage(LPMSG lpMsg,HWND hWnd,UINT wMsgFilterMin,UINT wMsgFilterMax);

　　 該函式用來獲取與hWnd引數所指定的視窗相關的且wMsgFilterMin和wMsgFilterMax引數所給出的訊息值範圍內的訊息。需要注意的是，如果hWnd為NULL，則GetMessage獲取屬於呼叫該函式應用程式的任一視窗的訊息，如果wMsgFilterMin和 wMsgFilterMax都是０，則GetMessage就返回所有可得到的訊息。函式獲取之後將刪除訊息佇列中的除WM_PAINT訊息之外的其他訊息，至於WM_PAINT則只有在其處理之後才被刪除。

　　 PeekMessage原型如下：BOOL PeekMessage(LPMSG lpMsg,HWND hWnd,UINT wMsgFilterMin,UINT wMsgFilterMax,UINT wRemoveMsg）；

　　 該函式用於檢視應用程式的訊息佇列，如果其中有訊息就將其放入lpMsg所指的結構中，不過，與GetMessage不同的是，PeekMessage函式不會等到有訊息放入佇列時才返回。同樣，如果hWnd為NULL，則PeekMessage獲取屬於呼叫該函式應用程式的任一視窗的訊息，如果 hWnd=-1，那麼函式只返回把hWnd引數為NULL的PostAppMessage函式送去的訊息。如果wMsgFilterMin和 wMsgFilterMax都是０，則PeekMessage就返回所有可得到的訊息。函式獲取之後將刪除訊息佇列中的除WM_PAINT訊息之外的其他訊息，至於WM_PAINT則只有在其處理之後才被刪除。

　　 WaitMessage原型如下：BOOL VaitMessage();當一個應用程式無事可做時，該函式就將控制權交給另外的應用程式，同時將該應用程式掛起，直到一個新的訊息被放入應用程式的佇列之中才返回。

　　 訊息的處理

　　 接下來我們談一下訊息的處理，首先我們來看一下VC中的訊息泵：

　　 while(GetMessage(&msg, NULL, 0, 0))
{
if(!TranslateAccelerator(msg.hWnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}

　　 首先，GetMessage從程式的主執行緒的訊息佇列中獲取一個訊息並將它複製到MSG結構，如果佇列中沒有訊息，則GetMessage函式將等待一個訊息的到來以後才返回。 如果你將一個視窗控制程式碼作為第二個引數傳入GetMessage，那麼只有指定視窗的的訊息可以從佇列中獲得。GetMessage也可以從訊息佇列中過濾訊息只接受訊息佇列中落在範圍內的訊息。這時候就要利用GetMessage／PeekMessage指定一個訊息過濾器。這個過濾器是一個訊息識別符號的範圍或者是一個窗體控制程式碼，或者兩者同時指定。當應用程式要查詢一個後入訊息佇列的訊息是很有用。WM_KEYFIRST 和 WM_KEYLAST 常量用於接受所有的鍵盤訊息。 WM_MOUSEFIRST 和 WM_MOUSELAST 常量用於接受所有的滑鼠訊息。

　　 然後TranslateAccelerator判斷該訊息是不是一個按鍵訊息並且是一個加速鍵訊息，如果是，則該函式將把幾個按鍵訊息轉換成一個加速鍵訊息傳遞給視窗的回撥函式。處理了加速鍵之後，函式TranslateMessage將把兩個按鍵訊息WM_KEYDOWN和WM_KEYUP轉換成一個 WM_CHAR，不過需要注意的是，訊息WM_KEYDOWN,WM_KEYUP仍然將傳遞給視窗的回撥函式。

　　 處理完之後，DispatchMessage函式將把此訊息傳送給該訊息指定的視窗中已設定的回撥函式。如果訊息是WM_QUIT，則 GetMessage返回０，從而退出迴圈體。應用程式可以使用PostQuitMessage來結束自己的訊息迴圈。通常在主視窗的 WM_DESTROY訊息中呼叫。

　　 下面我們舉一個常見的小例子來說明這個訊息泵的運用：

　　 if (::PeekMessage(&msg, m_hWnd, WM_KEYFIRST,WM_KEYLAST, PM_REMOVE))
{
if (msg.message == WM_KEYDOWN && msg.wParam == VK_ESCAPE)．．．
}

　　 這裡我們接受所有的鍵盤訊息，所以就用WM_KEYFIRST 和 WM_KEYLAST作為引數。最後一個引數可以是PM_NOREMOVE 或者 PM_REMOVE，表示訊息資訊是否應該從訊息佇列中刪除。

　　 所以這段小程式碼就是判斷是否按下了Esc鍵，如果是就進行處理。

視窗過程

　　 視窗過程是一個用於處理所有傳送到這個視窗的訊息的函式。任何一個視窗類都有一個視窗過程。同一個類的視窗使用同樣的視窗過程來響應訊息。 系統傳送訊息給視窗過程將訊息資料作為引數傳遞給他，訊息到來之後，按照訊息型別排序進行處理，其中的引數則用來區分不同的訊息，視窗過程使用引數產生合適行為。

　　 一個視窗過程不經常忽略訊息，如果他不處理，它會將訊息傳回到執行預設的處理。視窗過程通過呼叫DefWindowProc來做這個處理。視窗過程必須 return一個值作為它的訊息處理結果。大多數視窗只處理小部分訊息和將其他的通過DefWindowProc傳遞給系統做預設的處理。視窗過程被所有屬於同一個類的視窗共享，能為不同的視窗處理訊息。下面我們來看一下具體的例項：

　　　 LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
　　　 {
int wmId, wmEvent;
PAINTSTRUCT ps;
HDC hdc;
TCHAR szHello[MAX_LOADSTRING];
LoadString(hInst, IDS_HELLO, szHello, MAX_LOADSTRING);

switch (message)
{
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
// Parse the menu selections:
switch (wmId)
{
case IDM_ABOUT:
DialogBox(hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, (DLGPROC)About);
break;
case IDM_EXIT:
DestroyWindow(hWnd);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
break;
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
// TODO: Add any drawing code here...
RECT rt;
GetClientRect(hWnd, &rt);
DrawText(hdc, szHello, strlen(szHello), &rt, DT_CENTER);
EndPaint(hWnd, &ps);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
　　　 }
　　 return 0;
　　　 }

　　 訊息分流器

　　 通常的視窗過程是通過一個switch語句來實現的，這個事情很煩，有沒有更簡便的方法呢？有，那就是訊息分流器，利用訊息分流器，我們可以把switch語句分成更小的函式，每一個訊息都對應一個小函式，這樣做的好處就是對訊息更容易管理。

　　 之所以被稱為訊息分流器，就是因為它可以對任何訊息進行分流。下面我們做一個函式就很清楚了：

　　 void MsgCracker(HWND hWnd,int id,HWND hWndCtl,UINT codeNotify)
{
switch(id)
{
case ID_A:
if(codeNotify==EN_CHANGE)...
break;
case ID_B:
if(codeNotify==BN_CLICKED)...
break;
....
}
}

　　 然後我們修改一下視窗過程：

　　 LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch(message)
{
HANDLE_MSG(hWnd,WM_COMMAND,MsgCracker);
HANDLE_MSG(hWnd,WM_DESTROY,MsgCracker);
default:
return DefWindowProc(hWnd, message, wParam, lParam);
　　　 }
　　 return 0;
　　　 }

　　 在WindowsX.h中定義瞭如下的HANDLE_MSG巨集：

　　　 #define HANDLE_MSG(hwnd,msg,fn)
switch(msg): return HANDLE_##msg((hwnd),(wParam),(lParam),(fn));

　　 實際上，HANDLE_WM_XXXX都是巨集，例如：HANDLE_MSG(hWnd,WM_COMMAND,MsgCracker);將被轉換成如下定義：

　　　 #define HANDLE_WM_COMMAND(hwnd,wParam,lParam,fn)
((fn)((hwnd),(int)(LOWORD(wParam)),(HWND)(lParam),(UINT)HIWORD(wParam)),0L);

　　 好了，事情到了這一步，應該一切都明朗了。

　　 不過，我們發現在windowsx.h裡面還有一個巨集：FORWARD_WM_XXXX，我們還是那WM_COMMAND為例，進行分析：

　　　 #define FORWARD_WM_COMMAND(hwnd, id, hwndCtl, codeNotify, fn)
(void)(fn)((hwnd), WM_COMMAND, MAKEWPARAM((UINT)(id),(UINT)(codeNotify)), (LPARAM)(HWND)(hwndCtl))

　　 所以實際上，FORWARD_WM_XXXX將訊息引數進行了重新構造，生成了wParam && lParam，然後呼叫了我們定義的函式。

MFC訊息的處理實現方式

　　 初看MFC中的各種訊息，以及在頭腦中根深蒂固的C++的影響，我們可能很自然的就會想到利用C++的三大特性之一：虛擬機器制來實現訊息的傳遞，但是經過分析，我們看到事情並不是想我們想象的那樣，在MFC中訊息是通過一種所謂的訊息對映機制來處理的。

　　 為什麼呢？在潘愛民老師翻譯的《Visual C++技術內幕》（第4版）中給出了詳細的原因說明，我再簡要的說一遍。在CWnd類中大約有110個訊息，還有其它的MFC的類呢，算起來訊息太多了，在C++中對程式中用到的每一個派生類都要有一個vtable，每一個虛擬函式在vtable中都要佔用一個4位元組大小的入口地址，這樣一來，對於每個特定型別的視窗或控制元件，應用程式都需要一個440KB大小的表來支援虛擬訊息控制元件函式。

　　 如果說上面的視窗或控制元件可以勉強實現的話，那麼對於選單命令訊息及按鈕命令訊息呢？因為不同的應用程式有不同的選單和按鈕，我們怎麼處理呢？在MFC庫的這種訊息對映系統就避免了使用大的vtable，並且能夠在處理常規Windows訊息的同時處理各種各樣的應用程式的命令訊息。

　　 說白了，MFC中的訊息機制其實質是一張巨大的訊息及其處理函式的一一對應表，然後加上分析處理這張表的應用框架內部的一些程式程式碼.這樣就可以避免在SDK程式設計中用到的繁瑣的CASE語句。

　　 MFC的訊息對映的基類CCmdTarget

　　 如果你想讓你的控制元件能夠進行訊息對映，就必須從CCmdTarget類中派生。CCmdTarget類是MFC處理命令訊息的基礎、核心。MFC為該類設計了許多成員函式和一些成員資料，基本上是為了解決訊息對映問題的，所有響應訊息或事件的類都從它派生，例如：應用程式類、框架類、文件類、檢視類和各種各樣的控制元件類等等，還有很多。

　　 不過這個類裡面有２個函式對訊息對映非常重要，一個是靜態成員函式DispatchCmdMsg，另一個是虛擬函式OnCmdMsg。

　　 DispatchCmdMsg專門供MFC內部使用，用來分發Windows訊息。OnCmdMsg用來傳遞和傳送訊息、更新使用者介面物件的狀態。

　　 CCmdTarget對OnCmdMsg的預設實現：在當前命令目標(this所指)的類和基類的訊息對映陣列裡搜尋指定命令訊息的訊息處理函式。

　　 這裡使用虛擬函式GetMessageMap得到命令目標類的訊息對映入口陣列_messageEntries，然後在陣列裡匹配命令訊息ID相同、控制通知程式碼也相同的訊息對映條目。其中GetMessageMap是虛擬函式，所以可以確認當前命令目標的確切類。

　　 如果找到了一個匹配的訊息對映條目，則使用DispachCmdMsg呼叫這個處理函式；

　　 如果沒有找到，則使用_GetBaseMessageMap得到基類的訊息對映陣列，查詢，直到找到或搜尋了所有的基類（到CCmdTarget）為止；

　　 如果最後沒有找到，則返回FASLE。

　　 每個從CCmdTarget派生的命令目標類都可以覆蓋OnCmdMsg，利用它來確定是否可以處理某條命令，如果不能，就通過呼叫下一命令目標的 OnCmdMsg，把該命令送給下一個命令目標處理。通常，派生類覆蓋OnCmdMsg時 ，要呼叫基類的被覆蓋的OnCmdMsg。

　　 在MFC框架中，一些MFC命令目標類覆蓋了OnCmdMsg，如框架視窗類覆蓋了該函式，實現了MFC的標準命令訊息傳送路徑。必要的話，應用程式也可以覆蓋OnCmdMsg，改變一個或多個類中的傳送規定，實現與標準框架傳送規定不同的傳送路徑。例如，在以下情況可以作這樣的處理：在要打斷髮送順序的類中把命令傳給一個非MFC預設物件；在新的非預設物件中或在可能要傳出命令的命令目標中。

　　 訊息對映的內容

　　 通過ClassWizard為我們生成的程式碼，我們可以看到，訊息對映基本上分為2大部分：

　　 在標頭檔案(.h)中有一個巨集DECLARE_MESSAGE_MAP()，他被放在了類的末尾，是一個public屬性的；與之對應的是在實現部分（.cpp)增加了一章訊息對映表，內容如下：

BEGIN_MESSAGE_MAP(當前類, 當前類的基類)
file://{{AFX_MSG_MAP(CMainFrame)

　 訊息的入口項

file://}}AFX_MSG_MAP
END_MESSAGE_MAP()

　　 但是僅是這兩項還遠不足以完成一條訊息，要是一個訊息工作，必須有以下3個部分去協作：
1.在類的定義中加入相應的函式宣告；

　 2.在類的訊息對映表中加入相應的訊息對映入口項；

　 3.在類的實現中加入相應的函式體；

　　 訊息的新增

　　 有了上面的這些只是作為基礎，我們接下來就做我們最熟悉、最常用的工作：新增訊息。MFC訊息的新增主要有2種方法：自動/手動，我們就以這2種方法為例，說一下如何新增訊息。

　　 1、利用Class Wizard實現自動新增

　　 在選單中選擇View--&gtClass Wizard，也可以用單擊滑鼠右鍵，選擇Class Wizard，同樣可以啟用Class Wizard。選擇Message Map標籤，從Class name組合框中選取我們想要新增訊息的類。在Object IDs列表框中，選取類的名稱。此時， Messages列表框顯示該類的大多數(若不是全部的話)可過載成員函式和視窗訊息。類過載顯示在列表的上部，以實際虛構成員函式的大小寫字母來表示。其他為視窗訊息，以大寫字母出現，描述了實際視窗所能響應的訊息ID。選中我們向新增的訊息，單擊Add Function按鈕，Class Wizard自動將該訊息新增進來。

　　 有時候，我們想要新增的訊息本應該出現在Message列表中，可是就是找不到，怎麼辦？不要著急，我們可以利用Class Wizard上Class Info標籤以擴充套件訊息列表。在該頁中，找到Message Filter組合框，通過它可以改變首頁中Messages列表框中的選項。這裡，我們選擇Window，從而顯示所有的視窗訊息，一把情況下，你想要新增的訊息就可以在Message列表框中出現了，如果還沒有，那就接著往下看：）

　　 2、手動地新增訊息處理函式

　　 如果在Messages列表框中仍然看不到我們想要的訊息，那麼該訊息可能是被系統忽略掉或者是你自己建立的，在這種情況下，就必須自己手工新增。根據我們前面所說的訊息工作的3個部件，我們一一進行處理：

　　 1) 在類的. h檔案中新增處理函式的宣告，緊接在//}}AFX_MSG行之後加入宣告，注意：一定要以afx_msg開頭。

　　 通常，新增處理函式宣告的最好的地方是原始碼中Class Wizard維護的表下面，但是在它標記其領域的｛｛｝｝括弧外面。這些括弧中的任何東西都將會被Class Wizard銷燬。

　　 2) 接著，在使用者類的.cpp檔案中找到//}}AFX_MSG_MAP行，緊接在它之後加入訊息入口項。同樣，也是放在{ {} }的外面

　　 3) 最後，在該檔案中新增訊息處理函式的實體。 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25897606/viewspace-704359/，如需轉載，請註明出處，否則將追究法律責任。