[翻譯]-WinCE 程式設計 (3rd 版)–1.5 Windows應用程式剖析

Windows應用程式剖析
基於Windows的編程遠不同於基於MS-DOS或Unix的編程。只要是程式需要，任何時候基於MS-DOS或Unix的程式都可以使用getc-或putc風格的函數從鍵盤讀取字元並寫到螢幕上。這是MS-DOS或Unix程式所使用的典型的"Pull"（拉）風格，這種風格是面向過程的，而一個Windows程式，則使用"Push"（推）模式。在這種模式下，必須編寫程式來響應來自作業系統的通知，比如一個鍵被壓下去了或者收到一個重繪螢幕的命令。

Windows應用程式並不從作業系統請求輸入，而是由作業系統通知應用程式輸入產生了。作業系統通過發送訊息（messages）給應用程式視窗來完成這些通知。所有視窗都是視窗類別的具體執行個體。在進一步深入之前，讓我們先確保理解這些術語。

視窗類別
視窗是螢幕上的一個地區，除了特殊情況，基本上都是矩形。視窗有一些基本參數，比如位置參數--x,y和z（視窗在螢幕其它視窗之上或者之下）--可視性以及層次關係--視窗與系統案頭形成父子視窗關係，系統案頭也是一個視窗。

每個被建立的視窗都是視窗類別的一個具體執行個體。視窗類別是一個模板，為該類的所有視窗定義了許多共同屬性。換句話說，屬於同一個類的視窗有同樣的屬性。這些共用的屬性中最重要的是視窗過程。

視窗過程
視窗類別裡視窗過程中的代碼定義了同一個類裡所有視窗的行為。視窗過程處理髮到視窗的所有通知和請求。這些通知，要麼是作業系統發給視窗，告訴視窗有事件發生，視窗必須回應，要麼是其他視窗發來的，向該視窗查詢資訊。

這些通知是以訊息的形式發送的。訊息實際就是對視窗過程的一次調用，帶有參數指出通知或者查詢的種類。當有事件發生，例如視窗被移動、被改變大小或有鍵被按下去等，就會發送訊息。標識訊息的值由Windows定義。應用程式使用預定義好的常量，例如WM_CREATE和 WM_MOVE，來表示訊息。因為有很多訊息可被發送，所以當視窗類別對某個訊息沒有特殊處理的必要時，Windows提供了一個預設處理函數來處理傳遞這些訊息。

訊息生命週期
讓我們回頭一會，看一下Windows是如何協調發到系統裡各個視窗的各種訊息的。Windows監視系統的所有輸入，例如鍵盤、滑鼠、觸控螢幕以及其它可以產生影響視窗的事件的硬體。當事件發生後，訊息就被構成並定向給特定的視窗。Windows沒有直接調用視窗過程，而是加了一個中間步驟。訊息被放到擁有該視窗的應用程式的訊息佇列裡了。當應用程式準備接收訊息的時候，它把訊息從隊列裡取出來，並告訴Windows發送該訊息到應用程式適當的視窗上。

你可能會認為這個過程中涉及許多中間步驟，那麼你是對的。就讓我們分解一下這個過程吧。
1、當事件發生，Windows就構成一個訊息並放到擁有目的視窗的應用程式的訊息佇列裡。和在XP裡一樣，在Windows CE中，每個應用程式有自己單獨的訊息佇列[1] （這與Windows3.1及更早的Windows版本不同，那時只有唯一一個系統範圍內的訊息佇列）。事件發生及構成一個訊息都要比應用程式處理它們的速度快。雖然程式最好能快速響應或者使用者希望看到應用程式快速響應，但是隊列允許應用程式按自己的速率處理訊息。訊息佇列允許Windows在運做中設定一個通知並繼續完成其它任務，而不是僅僅限制在只響應收到訊息的這個應用程式。

2、應用程式把訊息從訊息佇列中移出來，並回調Windows來指派訊息。似乎很奇怪應用程式從隊列裡獲得訊息卻只是簡單的回調Windows來處理這個訊息，對這種方式，解釋如下：應用程式從隊列裡擷取訊息，這使得應用程式在請求Windows把訊息指派到相應視窗之前，可以預先處理這些訊息。許多情況下，應用程式會調用Windows裡不同的函數來處理具體的各種訊息。

3、Windows分發訊息，更確切的說，是Windows調用相應的視窗過程。沒有讓應用程式直接調用視窗過程，而是間接調用，這允許Windows協調這個視窗過程的調用與系統裡的其它事件。雖然此刻訊息並不在另外一個隊列裡，但Windows在調用視窗過程之前，可能需要做一些預先處理。但無論如何，這種調度方式減少了應用程式的責任，不用程式去決定適當的目的視窗，而是由Windows負責了。

4、視窗過程處理訊息。所有的視窗過程都有相同的調用參數：被調用的視窗執行個體的控制代碼、訊息參數、兩個普通參數，包含與訊息相關的資料。視窗過程用視窗控制代碼區分視窗的每個執行個體。訊息參數，指明視窗必須響應的事件。兩個普通包含與訊息相關的資料。例如，WM_MOVE訊息指出視窗將被移動，其中一個普通參數指向一個包含視窗新座標的結構。

註：技術上，Windows CE應用程式的每個線程都有一個訊息佇列。稍後我將在本書裡討論區對話。