MFC 捛膚與子類化技術全景解析：七大方案優劣比較與實戰避坑指南

應用程式「換膚」本質上是對視窗控制項進行子類化，攔截繪製訊息實現自訂外觀。本文系統梳理七種主流方案，深入剖析子類化衝突、系統對話框處理、滾動條換膚等實戰難題，並提供自訂 CWndNew 類別解決重複子類化問題。

一、七大換膚方案總覽

二、核心難題與解決方案

1. 重複子類化崩潰

MFC DDX_Control 內部呼叫 SubclassWindow，若 Hook 中再次 SubclassWindow 同一 HWND，會觸發 ASSERT 或崩潰。

解決：

• 方案 A：Hook 中僅宣告指標，動態 new CButtonXP，但無法透過 DDX 管理。
• 方案 B：將 Hook 邏輯放入 DLL，EXE 與 DLL 分別子類化不同模組的視窗（實測可行）。
• 方案 C：改用 SetWindowLong(GWL_WNDPROC) 繞過 MFC 子類化機制（本文採用）。

2. 子類化順序與 WM_NCDESTROY 清理

多層子類化鏈中，必須確保反向順序清理。關鍵原則：

• 勿在 Hook 中處理 WM_NCDESTROY（會搶先於 MFC）。
• 在自訂 WindowProc 中處理 WM_NCDESTROY，檢查當前 GWL_WNDPROC 是否為自己，決定是否 Unsubclass 並傳遞訊息。

case WM_NCDESTROY:
    WNDPROC cur = (WNDPROC)GetWindowLong(m_hWnd, GWL_WNDPROC);
    if (cur == CWndNew::StaticWindowProc) {
        HWND h = m_hWnd;
        UnsubclassWindow(); // 恢復舊 WndProc
        return CallWindowProc(m_oldProc, h, uMsg, wParam, lParam);
    } else {
        LRESULT ret = CallWindowProc(m_oldProc, m_hWnd, uMsg, wParam, lParam);
        if (cur == (WNDPROC)GetWindowLong(m_hWnd, GWL_WNDPROC))
            UnsubclassWindow();
        delete this;
        return ret;
    }

3. 系統對話框子類化（MessageBox、FileDialog）

• 類別名不固定（#32770 為對話框，但主視窗類別名不可預測）。
• CFileDialog 中 CStatic 背景重繪異常：需在 OnPaint 明確繪製背景或呼叫 CStatic::OnPaint()。
• 建議：針對已知系統對話框類別名（#32770、ToolbarWindow32 等）精準攔截，避免全域攔截副作用。

4. 滾動條換膚

內建滾動條非獨立視窗，Spy++ 可見其本質。常見做法：隱藏原滾動條（ModifyStyle(WS_VSCROLL,0)），自繪或使用 CScrollBar 控制項替代。Skin++ 等商業庫可能攔截 WM_NCPAINT 實現無縫換膚。

三、自訂輕量級 CWndNew 類別

為解決重複子類化、簡化訊息分發，作者實作 CWndNew：

• 靜態 std::map<HWND, CWndNew*> 維護 HWND 與實例對應。
• StaticWindowProc 為靜態回呼，查表轉發至虛擬 WindowProc。
• 支援 SubclassWindow/UnsubclassWindow、虛擬 PresubclassWindow/PostunsubclassWindow 鉤子。
• 不支援多執行緒、訊息映射、繼承鏈，但輕量且解決核心衝突。

四、總結與建議

• 簡單專案：方案 1（直接繼承）+ Manifest 最划算。
• 中大型專案需統一風格：方案 2/3（Hook）+ 自訂 CWndNew，集中管理、隔離衝突。
• 追求極致體驗、預算允許：Skin++ 等成熟庫。
• 切記：子類化必須成對出現（Subclass/Unsubclass），WM_NCDESTROY 是最後清理良機。

完整代碼與討論串請參考文末連結。歡迎交流更優雅的換膚架構設計。