上次
說了hook和視窗類的原理，有了hook，我們可以擷取所有訊息，有了視窗類，我們可以識別視窗型別，不同型別的視窗給予不同處理。這樣，我們要在鉤子函式裡面識別不同的視窗和不同的訊息，有大量的分派工作，更要命的是，光區分視窗類還不夠，同型別的不同視窗經常需要不同的處理，例如兩個button視窗，大小不同，文字不同，是否有滑鼠按下不同...... 這些狀態有些是可以從button視窗讀到的，例如大小和文字，而有些則讀不到，比如是否有滑鼠按下，對這些讀不到的狀態，我們必須自己記錄，例如在收到wm_lbuttondown訊息時記下按鈕被按下了。也就是說，對於每個視窗，我們還需要記錄一些與其相對應的資料，以便在收到wm_paint訊息時做不同處理。把所有這些邏輯寫在鉤子函式裡顯然太麻煩了，即使能寫出來也沒法維護，我們需要乙個好的設計。
根據物件導向的思想，我們需要為每種視窗型別寫乙個類，並為每個視窗生成乙個對應類的例項，由這些例項來處理視窗訊息，並記錄必要的視窗狀態資料。這樣，處理視窗訊息的任務就交給這些物件了，那麼，怎麼把訊息傳遞給這些物件呢，用鉤子函式**是一種方案，不過我們這裡採用了另一種：subclasswindow，關於subclasswindow的原理，就不多講了，可以參看msdn，其實就是替換乙個視窗過程函式。atl提供了現成的支援，用起來還是很方便的，替代的視窗過程函式不用全部自己寫，而可以用訊息對映巨集生成。
現在我們用subclasswindow的方式可以直接把我們的物件鏈結到視窗的訊息鏈中，這好像有點和鉤子函式的功能重複了，因為鉤子函式本來就是用來截獲訊息的。現在subclasswindow以後，視窗的訊息已經可以被截獲了，那還要鉤子函式幹什麼呢。
答案是：鉤子函式用來執行subclasswindow操作。原因有兩個，第一，我們要做的是乙個skin plugin，我們希望使用者呼叫乙個函式就可以改變整個介面風格，而不是為每個視窗呼叫subclasswindow函式；第二，有些視窗的建立根本不是在**裡控制的，例如選單視窗，除了使用鉤子函式，我們甚至不能獲得選單視窗的控制代碼。所以，我們必須使用鉤子函式，但在鉤子函式中，我們只處理乙個訊息：wm_create，在任何乙個可識別視窗建立時，生成乙個對於的物件例項，並用subclasswindow掛接這個例項到目標視窗，剩下的事情讓這個物件例項去完成。
粗略的設計已經有了，總結一下：
1、為每種可識別的視窗類編寫類，實現必要的訊息處理和狀態儲存；
2、用鉤子函式擷取wm_create訊息，並建立對應的類例項；
3、通過subclasswindow操作把生成的類例項掛接到目標視窗，完成訊息處理和狀態儲存的工作；
編輯
收藏
# re: skin技術實現框架（三） 2004-05-19 18:06
yanxm
在codeproject上就看到這篇文章的e文版。覺得很有創意，在這裡先謝過了。希望看到後續文章。 #
re: skin技術實現框架（三） 2004-05-19 20:37
vibration
會繼續寫的，中文可以寫的詳細些，e文就只能盡量精簡了，可能很多地方都沒有講清楚:p #
re: skin技術實現框架（三） 2004-05-20 09:51
yanxm
m_nstate = state_normal;
m_btracking = false;
if(basetype_button==getbasetype())
}3,
long getbasetype()
以上綠顏色是我增加的部分。 #
re: skin技術實現框架（三） 2004-05-20 13:29
vibration
使用ownerdraw也是一種實現方式，原來的**沒有用這種方法是考慮到宿主系統可能本來有ownerdraw按鈕 #
re: skin技術實現框架（三） 2004-09-15 13:02
快樂風
轉貼 Skin技術實現框架（四）
今天有點空了，繼續寫。上次我們已經得出了基本的設計，由此確定了每種視窗必須有乙個類來與之對應，這裡所說的視窗種類是按照視窗的windows class名稱來區分的，class名稱相同的就認為是一種視窗。這種分類方法和我們看到的視窗種類可能有一些差異，例如，普通按鈕，單選按鈕和核取方塊的類名都是 bu...
app開發的三大技術框架
2.型別特點 1 native 原生 產品特點 偏操作互動多的工具類應用 維護成本 不僅要維護多個系統版本，還要維護多個歷史版本 如有的使用者在5.0版本，有的使用者在4.0版本等 資源儲存 本地 網路要求 支援離線 人員配比 需要ios android和wp各自系統的開發人員 2 web 維護成本...
nuxt框架前後端登入註冊功能實現 三
流程圖 登入核心 呼叫介面發起登入請求 login.loginuser this user then response 第三步在requests.js建立 第四步呼叫介面，通過token獲取使用者資訊並存在cookie中 login.getuserinfobytoken then response ...