隊列消息和非隊列消息
從消息的發送途徑來看，消息可以分成2種：隊列消息和非隊列消息。消息隊列由可以分成系統消息隊列和線程消息隊列。系統消息隊列由Windows維護，線程消息隊列則由每個GUI線程自己進行維護，為避免給non-GUI現成創建消息隊列，所有線程產生時並沒有消息隊列，僅當線程第一次調用GDI函數數系統給線程創建一個消息隊列。隊列消息送到系統消息隊列，然後到線程消息隊列；非隊列消息直接送給目的窗口過程。
對於隊列消息，最常見的是鼠標和鍵盤觸發的消息，例如WM_MOUSERMOVE,WM_CHAR等消息，還有一些其它的消息，例如：WM_PAINT、WM_TIMER和WM_QUIT。當鼠標、鍵盤事件被觸發後，相應的鼠標或鍵盤驅動程序就會把這些事件轉換成相應的消息，然後輸送到系統消息隊列，由Windows系統去進行處理。Windows系統則在適當的時機，從系統消息隊列中取出一個消息，根據前面我們所說的MSG消息結構確定消息是要被送往那個窗口，然後把取出的消息送往創建窗口的線程的相應隊列，下面的事情就該由線程消息隊列操心了，Windows開始忙自己的事情去了。線程看到自己的消息隊列中有消息，就從隊列中取出來，通過操作系統發送到合適的窗口過程去處理。
一般來講，系統總是將消息Post在消息隊列的末尾。這樣保證窗口以先進先出的順序接受消息。然而,WM_PAINT是一個例外，同一個窗口的多個 WM_PAINT被合並成一個 WM_PAINT 消息, 合並所有的無效區域到一個無效區域。合並WM_PAIN的目的是為了減少刷新窗口的次數。
非隊列消息將會繞過系統隊列和消息隊列，直接將消息發送到窗口過程，。系統發送非隊列消息通知窗口，系統發送消息通知窗口。 例如,當用戶激活一個窗口系統發送WM_ACTIVATE, WM_SETFOCUS, and WM_SETCURSOR。這些消息通知窗口它被激活了。非隊列消息也可以由當應用程序調用系統函數產生。例如,當程序調用SetWindowPos系統發送WM_WINDOWPOSCHANGED消息。一些函數也發送非隊列消息，例如下面我們要談到的函數。
消息的發送
了解了上面的這些基礎理論之後，我們就可以進行一下簡單的消息發送與接收。
把一個消息發送到窗口有3種方式：發送、寄送和廣播。
發送消息的函數有SendMessage、SendMessageCallback、SendNotifyMessage、SendMessageTimeout；寄送消息的函數主要有PostMessage、PostThreadMessage、PostQuitMessage；廣播消息的函數我知道的只有BroadcastSystemMessage、BroadcastSystemMessageEx。
SendMessage的原型如下：LRESULT SendMessage(HWND hWnd,UINT Msg,WPARAM wParam,LPARAM lParam)，這個函數主要是向一個或多個窗口發送一條消息，一直等到消息被處理之後才會返回。不過需要注意的是，如果接收消息的窗口是同一個應用程序的一部分，那麼這個窗口的窗口函數就被作為一個子程序馬上被調用；如果接收消息的窗口是被另外的線程所創建的，那麼窗口系統就切換到相應的線程並且調用相應的窗口函數，這條消息不會被放進目標應用程序隊列中。函數的返回值是由接收消息的窗口的窗口函數返回，返回的值取決於被發送的消息。
PostMessage的原型如下：BOOL PostMessage(HWND hWnd,UINT Msg,WPARAM wParam,LPARAM lParam)，該函數把一條消息放置到創建hWnd窗口的線程的消息隊列中，該函數不等消息被處理就馬上將控制返回。需要注意的是，如果hWnd參數為HWND_BROADCAST，那麼，消息將被寄送給系統中的所有的重疊窗口和彈出窗口，但是子窗口不會收到該消息；如果hWnd參數為NULL，則該函數類似於將dwThreadID參數設置成當前線程的標志來調用PostThreadMEssage函數。
從上面的這２個具有代表性的函數，我們可以看出消息的發送方式和寄送方式的區別所在：被發送的消息是否會被立即處理，函數是否立即返回。被發送的消息會被立即處理，處理完畢後函數才會返回；被寄送的消息不會被立即處理，他被放到一個先進先出的隊列中，一直等到應用程序空線的時候才會被處理，不過函數放置消息後立即返回。
實際上，發送消息到一個窗口處理過程和直接調用窗口處理過程之間並沒有太大的區別，他們直接的唯一區別就在於你可以要求操作系統截獲所有被發送的消息，但是不能夠截獲對窗口處理過程的直接調用。
以寄送方式發送的消息通常是與用戶輸入事件相對應的，因為這些事件不是十分緊迫，可以進行緩慢的緩沖處理，例如鼠標、鍵盤消息會被寄送，而按鈕等消息則會被發送。
廣播消息用得比較少，BroadcastSystemMessage函數原型如下：
long BroadcastSystemMessage(DWORD dwFlags,LPDWORD lpdwRecipients,UINT uiMessage,WPARAM wParam,LPARAM lParam);該函數可以向指定的接收者發送一條消息，這些接收者可以是應用程序、可安裝的驅動程序、網絡驅動程序、系統級別的設備驅動消息和他們的任意組合。需要注意的是，如果dwFlags參數是BSF_QUERY並且至少一個接收者返回了BROADCAST_QUERY_DENY，則返回值為０，如果沒有指定BSF_QUERY，則函數將消息發送給所有接收者，並且忽略其返回值。
消息的接收
消息的接收主要有３個函數：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返回0，從而退出循環體。應用程序可以使用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中的處理。
未完（待續．．．）
