中文名 | 消息結構 | 分????類 | 寫作術語 |
---|
當然,也不是每條消息都具備這四個部分,有時可根據情況省略背景或結尾。從外部結構形態來看,常見的有:一、倒敘式,也稱“倒金字塔”結構,即把最重要的事實或結果放到導語中加以陳述。二、順敘式,也叫“金字塔”結構或編年結構,即按照事件發生的時間順序寫,便于對事件發展的各階段作明晰的介紹和概括的描述。三、懸念式,在開頭設置疑團,使讀者急于了解事件的發展和結果。然后在主體部分或結尾處解開懸念。四、視覺式,用形象化、立體化方法來寫,以典型細節、生動畫面反映和報道新聞事實。五、散文式。形式不拘一格,內容博而不雜,類似自由活潑的散文結構。
2100433B
又稱時間邏輯交叉順序結構,時間順序和邏輯順序可以互相滲入,也可不分主次地將兩種順序穿插、揉合起來寫.好處是既有利于面的展示,顯示出清晰的條理,又有利于點的深入,使消息具有剖析的色彩。
Windowsx.h包含了這樣一些內容:
宏API,窗口消息分流器,控件API;
所有的這些宏定義,可以使你的程序更加安全,簡潔,結構更清晰,大大提高程序的可讀性;其中窗口消息分流器(message cracker)是我們今天要討論的話題,它可以使我們的API程序變得更簡潔。下面就進入我們的主題:(有關windowsx.h的更多內容,可以參考 MS Knowledge Base Article #83456.)
消息分流器是Windows提供的一組宏定義,它的兩個最大的作用,用MS的話來說,就是:
● 安全的數據類型,因為消息分流器完成了大量的類型轉換的工作;
● 使程序向32位windows的轉化更簡單;
當然,使用消息分流器會大大改變程序的面貌,你也可以選擇不使用它。
下面我們就以一個對話框窗口的消息處理過程為例,看看消息分流器到底是怎么運作的。
1.消息分流器的基本使用
先看一個普通的窗口消息處理函數,它可能需要處理一些窗口的初始化,無效客戶區重繪等消息:
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
// ...
return 0;
case WM_PAINT:
// ...
return 0;
case WM_DESTROY:
//...
return 0;
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
而通過使用消息分流器,我們可以把每個case都寫到相應的消息處理函數中,就像下面這樣:
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
return HANDLE_WM_CREATE(hwnd, wParam, lParam, Cls_OnCreate);
case WM_PAINT:
return HANDLE_WM_PAINT(hwnd, wParam, lParam, Cls_OnPaint);
case WM_DESTROY:
return HANDLE_WM_DESTROY(hwnd, wParam, lParam, Cls_OnDestroy);
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
這里用到了三個宏定義:HANDLE_WM_CREATE, HANDLE_WM_PAINT, HANDLE_WM_DESTROY;這三個宏定義就是我們的三個消息分流器(別看叫什么分流器,說穿了也不值幾個錢,呵呵),它們在windowsx.h中的定義如下:
#define HANDLE_WM_CREATE(hwnd, wParam, lParam, fn)
((fn)((hwnd), (LPCREATESTRUCT)(lParam)) "para" label-module="para">
#define HANDLE_WM_PAINT(hwnd, wParam, lParam, fn)
((fn)(hwnd), 0L)
#define HANDLE_WM_DESTROYCLIPBOARD(hwnd, wParam, lParam, fn)
((fn)(hwnd), 0L)
把這三個宏定義替換回去,就變成:
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
case WM_CREATE:
return Cls_OnCreate(hwnd, (LPCREATESTRUCT)(lParam) "para" label-module="para">
// 如果處理了消息,則Cls_OnCreate應返回TRUE,導致WndProc返回0,否則Cls_OnCreate返回FALSE,導致WndProc返回-1;
case WM_PAINT:
return Cls_OnPaint(hwnd), 0L;
// 逗號表達式;Cls_OnPaint是void類型,這里返回0;
case WM_DESTROY:
return Cls_OnDestroy(hwnd), 0L; // 同Cls_OnPaint
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
之后我們就可以按照消息分流器的定義編寫相應的消息處理函數了:
BOOL Cls_OnCreate(HWND hwnd, LPCREATESTRUCT lpCreateStruct){…};
void Cls_OnPaint(HWND hwnd){…};
void Cls_OnDestroyClipboard(HWND hwnd){…};
windowsx.h還提供了一個更加簡化的方法:使用HANDLE_MSG宏,這個宏是這樣定義的:
#define HANDLE_MSG(hwnd, message, fn)
case (message): return HANDLE_##message((hwnd), (wParam), (lParam), (fn))
這個宏要做的就是根據不同的message(##用來連接前后的字符串),把自己“變成”相應的HANDLE_XXXXMESSAGE形式的宏,再通過相應的宏來執行消息處理代碼;
比如實際代碼中寫入:
HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate)
則經過轉換就變成:
case (WM_CREATE): return HANDLE_WM_CREATE((hwnd), (wParam), (lParam), (Cls_OnCreate))
這樣,我們就可以直接把程序寫為:
LRESULT CALLBACK WndProc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
HANDLE_MSG(hwnd, WM_CREATE, Cls_OnCreate);
HANDLE_MSG(hwnd, WM_PAINT, Cls_OnPaint);
HANDLE_MSG(hwnd, WM_DESTROY, Cls_OnDestroy);
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
之后直接編寫相應的消息處理過程就可以了。是不是簡潔多了?而且把消息處理封裝到函數里面,就可以使用VS直接跳轉到這個函數,再也不用費勁去找那個 case了。要注意的一點是,雖然windowsx.h里包括了所有消息對應的分流器,但它們的參數是宏定義顯式說明的,在編寫消息處理函數時,必須遵循宏定義中的參數類型,否則會導致錯誤;這么多消息分流器,我們每次新寫一個消息處理函數時就得看看是否把參數設置正確了,整個過程繁瑣冗長。好在已經有一個工具叫Message Cracker Wizard,可以幫助我們生成消息分流器和相關的處理過程。
2.在對話框中使用消息分流器
在對話框消息處理中,窗口子類化是我們經常使用的手段,這也可以通過消息分流器實現,但是有點小問題 :>
下面是一個使用了windowsx.h消息分流器的對話框及其處理過程:
……
int WINAPI _tWinMain(HINSTANCE hinstExe, HINSTANCE, PTSTR pszCmdLine, int)
{
DialogBoxParam(
hinstExe, MAKEINTRESOURCE(IDD_PASSTHRU), NULL, (DLGPROC)Dlg_Proc, 0);
return(0);
}
……
LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
HANDLE_MSG(hwnd, WM_INITDIALOG, Cls_OnInitDialog); // 不能直接使用HANDLE_MSG宏
HANDLE_MSG(hwnd, WM_COMMAND, Cls_OnCommand); // 不能直接使用HANDLE_MSG宏
}
return false;
}
以上程序中直接使用HANDLE_MSG可能導致錯誤;為什么呢?問題出在子類化的消息處理過程的返回值上,msdn中對于對話框消息處理過程的返回值有如下說明:
一般情況下,對話框過程函數應該在處理了消息的情況下返回TRUE,如果沒有處理,則返回FALSE。如果對話框過程返回了FALSE,那么對話框管理器為這條消息準備默認的對話操作。
如果對話框處理了一個需要特定返回值的消息,則對話框的返回值應該被設置為調用SetWindowLong(The SetWindowLong function changes an attribute of the specified window. The function also sets a 32-bit (long) value at the specified offset into the extra window memory of a window. )后的返回值,并在返回TRUE之前立即返回這個值。注意你必須立即調用SetWindowLong(這個函數用于調用窗口子類化的過程),這會導致DWL_MSGRESULT值被一個嵌套的對話框消息改寫。返回值為特定值的消息有:
· WM_CHARTOITEM
· WM_COMPAREITEM
· WM_CTLCOLORBTN
· WM_CTLCOLORDLG
· WM_CTLCOLOREDIT
· WM_CTLCOLORLISTBOX
· WM_CTLCOLORSCROLLBAR
· WM_CTLCOLORSTATIC
· WM_INITDIALOG
· WM_QUERYDRAGICON
· WM_VKEYTOITEM
看到沒有? 我們的消息WM_INITDIALOG也在其中,對這個消息進行處理的過程不能簡單的返回TRUE表示對消息進行了處理,而是另有其意;它將轉化為:
case (WM_INITDIALOG): return HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, Cls_OnInitDialog);
宏HANDLE_WM_INITDIALOG定義如下:
#define HANDLE_WM_INITDIALOG(hwnd, wParam, lParam, fn)
(LRESULT)(DWORD)(UINT)(BOOL)(fn)((hwnd), (HWND)(wParam), lParam)
對WM_INITDIALOG的處理,如果返回TRUE,則表示設置鍵盤焦點到對話框的默認控件,否則返回FALSE;這時好像還看不出什么問題,而對于我們的另外一個消息WM_COMMAND,HANDLE_MSG簡單的把它變成:
case (WM_COMMAND): return HANDLE_WM_COMMAND(hwnd, wParam, lParam, Cls_OnCommand);
宏HANDLE_WM_COMMAND定義如下:
#define HANDLE_WM_COMMAND(hwnd, wParam, lParam, fn)
((fn)((hwnd), (int)(LOWORD(wParam)), (HWND)(lParam), (UINT)HIWORD(wParam)), 0L)
問題出來了,我們的Cls_OnCommand由于是個void型的函數,是沒有返回值的,因此windows默認這種消息處理過程必須返回一個0值,而返回0值不就表示我們的消息過程不處理這個消息么?這個矛盾是HANDLE_MSG無法解決的。怎么辦才能使消息過程在處理完WM_COMMAND消息之后正確的返回一個TRUE呢? 答案是使用另一個windowsx.h中的宏:SetDlgMsgResult(hwnd, msg, result)
這個宏定義如下:
#define SetDlgMsgResult(hwnd, msg, result) ((
(msg) == WM_CTLCOLORMSGBOX ||
(msg) == WM_CTLCOLOREDIT ||
(msg) == WM_CTLCOLORLISTBOX ||
(msg) == WM_CTLCOLORBTN ||
(msg) == WM_CTLCOLORDLG ||
(msg) == WM_CTLCOLORSCROLLBAR ||
(msg) == WM_CTLCOLORSTATIC ||
(msg) == WM_COMPAREITEM ||
(msg) == WM_VKEYTOITEM ||
(msg) == WM_CHARTOITEM ||
(msg) == WM_QUERYDRAGICON ||
(msg) == WM_INITDIALOG
) "_blank" href="/item/SetWindowLongPtr">SetWindowLongPtr((hwnd), DWLP_MSGRESULT, (LPARAM)(LRESULT)(result)), TRUE))
(有沒有注意到,里面多了一個WM_CTLCOLORMSGBOX ? 這個消息是16位WinAPI中的消息,一度被轉換為Win32 API的一個消息;現在在最新的32位API中已經被刪除了;保留它可能考慮到兼容性的問題,這里不做進一步討論)
現在看到了,如果對話框過程處理的消息恰巧為返回特定值中的一個,則如實返回result;不要被前面的BOOL蒙蔽,BOOL在頭文件中的定義實際上是一個int型,一旦需要返回非TRUE或FALSE的其他值,照樣可以;這樣,我們的Cls_OnInitDialog就能夠正確的返回它的BOOL值了,而Cls_OnCommand在處理之后,也可以由后面的逗號表達式正確的返回一個TRUE表示消息已處理。
在《Windows核心編程》一書中,大牛Jeffrey自己定義了一個宏,使SetDlgMsgResult宏的使用更加方便:
#define chHANDLE_DLGMSG(hwnd, message, fn)
case (message): return (SetDlgMsgResult(hwnd, uMsg,
HANDLE_##message((hwnd), (wParam), (lParam), (fn))))
可見這個宏只是簡單的對SetDlgMsgRseult宏進行了封裝。
這樣,我們最終的代碼可以寫成:
LRESULT CALLBACK Dlg_Proc (HWND hwnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
switch(msg)
{
chHANDLE_DLGMSG(hwnd, WM_INITDIALOG, Cls_OnInitDialog); // 使用大牛的chHANDLE_DLGMSG宏
chHANDLE_DLGMSG(hwnd, WM_COMMAND, Cls_OnCommand);
}
return false;
}
下面把原來程序整個框架列出來:
LRESULT CALLBACK Dlg_Proc(HWND hwnd, UNIT umsg, WPARAM wparam, LPARAM lparam)
{
switch(msg)
{
case WM_COMMAND: // 每個case都被一個message cracker代替,這里使用大牛同志的
// do something; // chHANDLE_DLGMSG宏;這個宏負責對消息篩選,處理并返回相應的值
return true;
case WM_INITDIALOG:
// do something;
return xxxx;
}
return false; // 如果消息不在我們的DlgProc過程中被處理,則告訴調用這個DlgProc的消息,
} //告訴系統的對話框管理器,這個消息我們不處理,交給你了
對比一下,消息分流器的作用不言自明。
以上只是介紹了消息分流器的部分應用,更多創造性的用法還等你自己在實踐中發掘。
其實這個不是一個專業的定義詞匯 。
消息服務器作為網絡的節點,專門用來存儲、轉發網絡上的數據、信息(例如:聊天信息)。做一個形象的比喻:消息服務器就像是郵局的交換機,而微機、筆記本、PDA、手機等固定或移動的網絡終端,就如散落在家庭、各種辦公場所、公共場所等處的電話機。我們與外界日常的生活、工作中的電話交流、溝通,必須經過交換機,才能到達目標電話;同樣如此,我們利用個人電腦,PDA,手機等,發送消息,也必須經過消息服務器,因此也可以說是消息服務器在“組織”和“領導”這些接收消息設備。
它是網絡上一種為客戶端計算機提供各種消息服務的高性能的計算機。它的高性能主要體現在高速度的運算能力、長時間的可靠運行、強大的外部數據吞吐能力等方面。2100433B