簡介
訊息本身是作為一個記錄傳遞給應用程式的，這個記錄（一般在 C/C++/彙編 中稱為“結構體”）中包含了訊息的類型以及其他信息。例如，對單擊滑鼠所產生的訊息來說，這個記錄（結構體）中包含了單擊滑鼠的訊息號（WM_LBUTTONDOWN）、單擊滑鼠時的坐標(由X,Y值連線而成的一個32位整數)。這個記錄類型叫做TMsg。
在Delphi的Windows單元中是這樣聲明的：
type
TMsg = packed record
hwnd: HWND; / /視窗句柄
message: UINT; / /訊息常量標識符
wParam: WPARAM ; // 32位訊息的特定附加信息（以前是16位）
lParam: LPARAM ; // 32位訊息的特定附加信息
time: DWORD; / /訊息創建時的時間
pt: TPoint; / /訊息創建時的滑鼠位置
end ;
其中TPoint定義是：
TPoint= record
x:integer;
y:integer;
end;
在C語言中的定義是：
typedef struct Msg
{
HWND hwnd; / /視窗句柄
UINT message; / /訊息常量標識符
WPARAM wParam; // 32位訊息的特定附加信息
LPARAM lParam; // 32位訊息的特定附加信息
DWORD time; / /訊息創建時的時間
TPoint pt; / /訊息創建時的滑鼠位置
} TMsg;
typedef struct TPoint
{
int x;
int y;
}TPoint;
訊息內容
hwnd
32位的視窗句柄。視窗可以是任何類型的螢幕對象，因為Win32能夠維護大多數可視對象的句柄(視窗、對話框、按鈕、編輯框等)。
message
用於區別其他訊息的常量值，這些常量可以是Windows單元中預定義的常量，也可以是自定義的常量。
wParam
通常是一個與訊息有關的常量值，也可能是視窗或控制項的句柄。
lParam
通常是一個指向記憶體中數據的指針。
由於WParam、lParam和Pointer都是32位的，即等同於DWORD。因此，它們之間可以相互轉換。
訊息系統
Windows的訊息系統是由3個部分組成的：
·訊息佇列。Windows能夠為所有的應用程式維護一個訊息佇列。應用程式必須從訊息佇列中獲取
訊息，然後分派給某個視窗。
·訊息循環。通過這個循環機制應用程式從訊息佇列中檢索訊息，再把它分派給適當的視窗，然
後繼續從訊息佇列中檢索下一條訊息，再分派給適當的視窗，依次進行。
· 視窗過程。每個視窗都有一個視窗過程來接收傳遞給視窗的訊息，它的任務就是獲取訊息然後
回響它。視窗過程是一個回調函式；處理了一個訊息後，它通常要返回一個值給Windows。
注意回調函式是程式中的一種函式，它是由Windows或外部模組調用的。
一個訊息從產生到被一個視窗回響，其中有5個步驟：
1) 系統中發生了某個事件。
2) Windows把這個事件翻譯為訊息，然後把它放到訊息佇列中。
3)應用程式從訊息佇列中接收到這個訊息，把它存放在TMsg記錄中。
4)應用程式把訊息傳遞給一個適當的視窗的視窗過程。
5) 視窗過程回響這個訊息並進行處理。
步驟3和4構成了應用程式的訊息循環。訊息循環往往是Windows應用程式的核心，因為訊息循環使一個應用程式能夠回響外部的事件。訊息循環的任務就是從訊息佇列中檢索訊息，然後把訊息傳遞給適當的視窗。如果訊息佇列中沒有訊息，Windows就允許其他應用程式處理它們的訊息。
Windows作業系統最大的特點就是其圖形化的操作界面，其圖形化界面是建立在其訊息處理機制這個基礎之上的。如果不理解Windows訊息處理機制，肯定無法深入的理解Windows編程。可惜很多程式設計師對Windows訊息只是略有所聞，對其使用知之甚少，更不了解其內部實現原理，本文試著一步一步向大家披露我理解的Windows訊息機制。可以說，掌握了這一部分知識，就是掌握了Windows編程中的神兵利器，靈活運用它，將會極大的提高我們的編程能力。
訊息實現
訊息概述
Windows窗體是怎樣展現在螢幕上的呢？眾所周知，是通過API繪製實現的。Windows作業系統提供了一系列的API函式來實現界面的繪製功能，例如：
DrawText 繪製文字
DrawEdge 繪製框線
DrawIcon 繪製圖示
Bitmap 繪製點陣圖
Rectangle 繪製矩形
…
再複雜的程式界面都是通過這些函式來實現的。
那什麼時候調用這些函式呢？顯然我們需要一個控制中心，用來進行“發號施令”，我們還需要一個命令傳達機制，將命令即時的傳達到目的地。這個控制中心，就是一個動力源，就像一顆心臟，源源不斷地將血液送往各處。這個命令傳達機制就是Windows訊息機制，Windows訊息就好比是身體中的血液，它是命令傳達的使者。
Windows訊息控制中心一般是三層結構，其頂端就是Windows核心。Windows核心維護著一個訊息佇列，第二級控制中心從這個訊息佇列中獲取屬於自己管轄的訊息，後做出處理，有些訊息直接處理掉，有些還要傳送給下一級窗體(Window)或控制項（Control）。第二級控制中心一般是各Windows應用程式的Application對象。第三級控制中心就是Windows窗體對象，每一個窗體都有一個默認的窗體過程，這個過程負責處理各種接收到的訊息。如下圖所示：
說明圖（註：windows指windows作業系統；視窗：即windows視窗；窗體：包括視窗，以及有句柄的控制項；control指控制項，控制項本身也可能是一個window，也可能不是；Application即應用程式，應用程式也可能不會用到Windows訊息機制，這裡我們專門討論有訊息循環的應用程式）
訊息是以固定的結構傳送給應用程式的，結構如下：
Public Type MSG
hwnd As Long
message As Long
wParam As Long
lParam As Long
time As Long
pt As POINTAPI
End Type
其中hwnd是窗體的句柄，message是一個訊息常量，用來表示訊息的類型，wParam和lParam都是32位的附加信息，具體表示什麼內容，要視訊息的類型而定，time是訊息傳送的時間，pt是訊息傳送時滑鼠所在的位置。
Windows作業系統中包括以下幾種訊息：
1、標準Windows訊息：
這種訊息以WM_打頭。
2、通知訊息
通知訊息是針對標準Windows控制項的訊息。這些控制項包括：按鈕(Button)、組合框(ComboBox)、編輯框(TextBox)、列表框（ListBox）、ListView控制項、Treeview控制項、工具條(Toolbar)、選單（Menu）等。每種訊息以不同的字元串打頭。
3、自定義訊息
編程人員還可以自定義訊息。
句柄
不是每個控制項都能接收訊息，轉發訊息和繪製自身，只有具有句柄（handle）的控制項才能做到。有句柄的控制項本質上都是一個窗體(window)，它們可以獨立存在，可以作為其它控制項的容器，而沒有句柄的控制項，如Label，是不能獨立存在的，只能作為視窗控制項的子控制項，它不能繪製自身，只能依靠父窗體將它繪製來。
句柄的本質是一個系統自動維護的32位的數值，在整個作業系統的任一時刻，這個數值是唯一的。但該句柄代表的窗體釋放後，句柄也會被釋放，這個數值又可能被其它窗體使用。也就是說，句柄的數值是動態的，它本身只是一個唯一性標識，作業系統通過句柄來識別和查找它所代表的對象。
然而，並非所有的句柄都是窗體的句柄，Windows系統中還中很多其它類型的句柄，如畫布（hdc）句柄，畫筆句柄，畫刷句柄，應用程式句柄(hInstance)等。這種句柄是不能接收訊息的。但不管是哪種句柄，都是系統中對象的唯一標識。本文只討論窗體句柄。
那為什麼句柄使視窗具有了如此獨特的特性呢？實際是都是由於訊息的原因。由於有了句柄，窗體能夠接收訊息，也就知道了該什麼時候繪製自己，繪製子控制項，知道了滑鼠在什麼時候點擊了視窗的哪個部分，從而作出相應的處理。句柄就好像是一個人的身份證，有了它，你就可以從事各種社會活動；否則的話，你要么是一個社會看不到的黑戶，要么跟在別人後面，通過別人來證明你的存在。
訊息傳送
1、從訊息佇列獲取訊息：
可以通過PeekMessage或GetMessage函式從Windows訊息佇列中獲取訊息。Windows保存的訊息佇列是以執行緒(Thread)來分組的，也就是說每個執行緒都有自己的訊息佇列。
2、傳送訊息
傳送訊息到指定窗體一般通過以下兩個函式完成：SendMessage和PostMessage。兩個函式的區別在於：PostMessage函式只是向執行緒訊息佇列中添加訊息，如果添加成功，則返回True,否則返回False，訊息是否被處理，或處理的結果，就不知道了。而SendMessage則有些不同，它並不是把訊息加入到佇列里，而是直接翻譯訊息和調用訊息處理(執行緒向自己傳送訊息才是這樣)，直到訊息處理完成後才返回。所以，如果我們希望傳送的訊息立即被執行，就應該調用SendMessage。
還有一點，就是SendMessage傳送的訊息由於不會被加入到訊息佇列中（錯：執行緒向其他執行緒傳送訊息也是追加到其他執行緒的傳送訊息佇列的，即使這兩個執行緒在同一個進程也是如此），所以通過PeekMessage或GetMessage是不能獲取到由SendMessage傳送的訊息。
另外，有些訊息用PostMessage不會成功，比如wm_settext。所以不是所有的訊息都能夠用PostMessage的。
還有一些其它的傳送訊息API函式，如PostThreadMessage，SendMessageCallback，SendMessageTimeout，SendNotifyMessage等。
訊息循環
訊息循環是應用程式能夠持續存在的根本原因。如果循環退出，則應用程式就結束了。
我們來看一看Delphi中封裝的訊息循環是怎樣的：
第一步：程式開始運行(Run)
Application.Initialize; //初始化
Application.CreateForm(TForm1, Form1); //創建主窗體
Application.Run; //開始運行，準備進行訊息循環
如果不創建主窗體，應用程式同樣可以存在和運行。
第二步：開始調用訊息循環(HandleMessage)
procedure TApplication.Run;
begin
FRunning := True;
try
AddExitProc(DoneApplication);
if FMainForm <> nil then
begin
case CmdShow of
SW_SHOWMINNOACTIVE: FMainForm.FWindowState := wsMinimized;
SW_SHOWMAXIMIZED: MainForm.WindowState := wsMaximized;
end;
if FShowMainForm then
if FMainForm.FWindowState = wsMinimized then
Minimize else
FMainForm.Visible := True;
Repeat //註：循環開始
try
HandleMessage;
except
HandleException(Self);
end;
until Terminated; //循環結束條件
end;
finally
FRunning := False;
end;
end;
第三步：訊息循環中對訊息的處理。
procedure TApplication.HandleMessage;
var
Msg: TMsg;
begin
if not ProcessMessage(Msg) then Idle(Msg);
end;
function TApplication.ProcessMessage(var Msg: TMsg): Boolean;
var
Handled: Boolean;
begin
Result := False;
if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then
begin
Result := True;
if Msg.Message <> WM_QUIT then
begin
Handled := False;
if Assigned(FOnMessage) then FOnMessage(Msg, Handled);
if not IsHintMsg(Msg) and not Handled and not IsMDIMsg(Msg) and
not IsKeyMsg(Msg) and not IsDlgMsg(Msg) then
begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
end
else
FTerminate := True;
end;
end;
窗體過程實際上是一個回調函式。所謂的回調函式，實際上就是由Windows作業系統或外部程式調用的函式。回調函式一般都有規定的參數格式，以地址方式傳遞給調用者。視窗過程中是Windows作業系統調用了，在一個視窗創建的時候，在分配窗體句柄的時候就需要傳入回調函式地址。那為什麼我們平時編程看不到這個回調函式呢？這是由於我們的編程工具已經為我們生成了默認的窗體過程，這個過程的要做的事情就是判斷不同的訊息類型，然後做出不同的處理。例如可以為鍵盤或滑鼠輸入生成事件等。
訊息事件
事件本質上是對訊息的封裝，是IDE編程環境為了簡化編程而提供的有用的工具。這個封裝是在窗體過程中實現的。每種IDE封裝了許多Windows的訊息，例如：
| 事件 | 訊息 |
| OnActivate | WM_ACTIVATE |
| OnClick | WM_XBUTTONDOWN |
| OnCreate | WM_CREATE |
| OnDblClick | WM_XBUTTONDBLCLICK |
| OnKeyDown | WM_KEYDOWN |
| OnKeyPress | WM_CHAR |
| OnKeyUp | WIN_KEYUP |
| OnPaint | WM_PAINT |
| OnResize | WM_SIZE |
| OnTimer | WM_TIMER |
