事情的緣起是，耐不住寂寞，準(zhǔn)備開始造GUI的輪子。

GUI框架，要做的事情我想大概是這么幾步：

1. 實(shí)現(xiàn)回調(diào)函數(shù)的成員化。
2. 實(shí)現(xiàn)方便程度可接受的消息映射。
3. 確定上述核心部件的使用方式。
4. 制造大量的控件。

前三步要走的比較小心，第四步是體力勞動(dòng)。

第一步，Windows下可參考的是MFC方式、WTL方式，以及利用Window相關(guān)屬性中的某些空位。前不久剛初步看過(guò)WTL的機(jī)制，雖然當(dāng)時(shí)沒寫GUI框架的打算，不過(guò)也有點(diǎn)技術(shù)準(zhǔn)備的意思了。現(xiàn)學(xué)現(xiàn)用吧。這里一個(gè)可以預(yù)見的問題是64位兼容，現(xiàn)在沒有測(cè)試環(huán)境，先不管。

接下來(lái)看第二步了，所要做的事情就是把 WndProc 下的 一堆 case 有效地組織起來(lái)，或者換個(gè)寫法。之前還真不知道 MFC/WTL 的 BEGIN_MSG_MAP。以為很高深的，想不到就是拼裝成一個(gè)大的 WndProc。先抄了，做成一個(gè)可運(yùn)行的版本。但是，這方面會(huì)直接決定以后的大部分使用方式，單單抄一下意義不大。后來(lái)去 @OwnWaterloo 曾推薦過(guò)的 @cexer 的博客上逛了幾圈，第一圈看了一些描述性文字，第二圈大概看了下技術(shù)，第三圈是挖墳，那個(gè)傳說(shuō)中的 cppblog 第一高樓啊。。其中有一個(gè)使用方式很新穎，嗯……是那個(gè)不需要手動(dòng)寫映射代碼，直接實(shí)現(xiàn)消息處理函數(shù)的方式。不過(guò)我后來(lái)覺得還是不要這種樣子了，憑我個(gè)人的直覺，如果我寫下這樣的處理函數(shù)，我大概會(huì)因?yàn)椴恢篮螘r(shí)注冊(cè)了這個(gè)函數(shù)而找不到調(diào)用來(lái)源而感到郁悶。在Windows回調(diào)機(jī)制的影響下，我可能會(huì)很抱有偏見地認(rèn)為，只有直接來(lái)自WndProc的調(diào)用，才算是來(lái)源明確的，不需要繼續(xù)追蹤的——當(dāng)然，這是建立在我不熟悉這個(gè)框架的基礎(chǔ)上的。框架必然需要隱藏調(diào)用來(lái)源，以及其他一些細(xì)節(jié)，但是在這一步，我覺得稍微有點(diǎn)早。

剛才說(shuō)到的都是靜態(tài)綁定。現(xiàn)在我有點(diǎn)傾向于動(dòng)態(tài)綁定。從使用方便程度上來(lái)看，動(dòng)態(tài)綁定更具靈活性。從性能上，動(dòng)態(tài)綁定下，消息到處理函數(shù)的查找過(guò)程可以更快，靜態(tài)綁定只能遍歷。當(dāng)然，未必將“添加處理函數(shù)”這樣的接口提供給最終用戶，但是這個(gè)操作對(duì)于整個(gè)控件體系的形成應(yīng)該蠻有幫助的吧。比如MFC下一個(gè)控件類使用Message Map做了一些事情，繼承類就無(wú)法直接繼承這個(gè)動(dòng)作，于是可能需要做兩套處理函數(shù)調(diào)用機(jī)制，一套是給內(nèi)部繼承用的，一套是給用戶的。如果在最開始的基類保存一個(gè)消息映射，每個(gè)消息對(duì)應(yīng)一族處理函數(shù)，每個(gè)繼承類都可以添加處理函數(shù)，但不刪除父類已添加的函數(shù)，這樣就可以在一套Message Map機(jī)制下獲得父類的行為。以上，不知道考慮得對(duì)不對(duì)，歡迎討論。

其中，父類保存子類給出的可調(diào)用體并正確執(zhí)行是個(gè)問題。折騰了一些時(shí)間，都沒有成功。我比較糾結(jié)，想知道除了用function之類的玩意兒外還有沒有其他簡(jiǎn)單可行的辦法。后來(lái)去@zblc的群上問，@vczh也說(shuō)需要一套function機(jī)制。看來(lái)是逃不開這個(gè)問題了。嗯……想起來(lái)大約兩個(gè)月前一個(gè)同事從codeproject找來(lái)了一個(gè)GUI框架看，看到幾行整整齊齊的 AddMsgHandler(WM_CREATE, XXX(this, &MyWindow::OnCreate));，嘆不已。我當(dāng)時(shí)打趣說(shuō)，這很簡(jiǎn)單的，無(wú)非是搞了個(gè) function 而已，哥哥兩天就能搞定。于是他們叫我兩天搞定。我鼓搗了10分鐘，搞不定，只好丟一句，真的很簡(jiǎn)單的，類似boost::function，你去看一下就知道了，哥哥要干活了。

既然現(xiàn)在還是繞不開這個(gè)問題，那還是搞一下了，搞好以后就權(quán)且當(dāng)做給他們交作業(yè)吧。我會(huì)另寫一篇文章說(shuō)說(shuō)function的事情，這里先略過(guò)。現(xiàn)在開始假設(shè)這個(gè)設(shè)施已經(jīng)造好了。那么，窗口類中大概可以這么定義相關(guān)類型：

typedef Function<bool (WPARAM, LPARAM)> MsgHandler;
typedef List<MsgHandler> MsgHandlerList;
typedef Map<UINT, MsgHandlerList> MsgMap;

然后再定義一個(gè)變量：

MsgMap  m_MsgMap;

它用于保存消息映射。最終的回調(diào)函數(shù)可以寫成：

LRESULT WndProc(UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    bool bHandled = false;

    MsgMap::Iterator itMsgMap = m_MsgMap.Find(uMsg);

    if (itMsgMap != m_MsgMap.End())
    {
        for (MsgHandlerList::Iterator it = itMsgMap->Value.Begin();
             !bHandled && it != itMsgMap->Value.End(); ++it)
        {
            bHandled = (*it)(wParam, lParam);
        }
    }

    return bHandled ? TRUE : DefWindowProc(m_hWnd, uMsg, wParam, lParam);
}

最后給個(gè)添加消息映射的接口：

void AppendMsgHandler(UINT uMsg, MsgHandler pMsgHandler)
{
    m_MsgMap[uMsg].PushBack(pMsgHandler);
}

到目前為止，我們的窗口類大致上可以寫成這樣：

#include <Windows.h>
#include <tchar.h>
#include "../GUIFramework/xlWindowBase.h"

class Window : public xl::WindowBase
{
public:
    Window()
    {
        AppendMsgHandler(WM_ERASEBKGND, MsgHandler(this, &Window::OnEraseBackground));
        AppendMsgHandler(WM_PAINT,      MsgHandler(this, &Window::OnPaint));
        AppendMsgHandler(WM_LBUTTONUP,  MsgHandler(this, &Window::OnLButtonUp));
        AppendMsgHandler(WM_RBUTTONUP,  MsgHandler(this, &Window::OnRButtonUp));
        AppendMsgHandler(WM_DESTROY,    MsgHandler(this, &Window::OnDestroy));
    }

protected:
    bool OnEraseBackground(WPARAM wParam, LPARAM lParam)
    {
        return false;
    }

    bool OnPaint(WPARAM wParam, LPARAM lParam)
    {
        PAINTSTRUCT ps = {};
        BeginPaint(m_hWnd, &ps);

        RECT rect = { 200, 200, 400, 400 };
        DrawText(ps.hdc, _T("Hello, world!"), -1, &rect, DT_CENTER | DT_VCENTER);

        EndPaint(m_hWnd, &ps);
        return false;
    }

    bool OnLButtonUp(WPARAM wParam, LPARAM lParam)
    {
        MessageBox(m_hWnd, _T("LButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
        return false;
    }

    bool OnRButtonUp(WPARAM wParam, LPARAM lParam)
    {
        MessageBox(m_hWnd, _T("RButtonUp"), _T("Message"), MB_OK | MB_ICONINFORMATION);
        return false;
    }

    bool OnDestroy(WPARAM wParam, LPARAM lParam)
    {
        PostQuitMessage(0);
        return false;
    }
};

在最基礎(chǔ)的 WindowBase 里，搞成這樣大概差不是很多了。暫時(shí)先看第三步。到目前為止，我所聽說(shuō)過(guò)的 GUI 框架都是真正的框架，似乎沒有“GUI 庫(kù)”。為什么一定要以繼承某個(gè)基類的方式來(lái)使用呢？如果像下面這樣使用呢？

class Window
{
private:
    xl::WindowBase m_WindowBase;

public:
    Window()
    {
        m_WindowBase.AppendMsgHandler(WM_ERASEBKGND, MsgHandler(this, &Window::OnEraseBackground));
        m_WindowBase.AppendMsgHandler(WM_PAINT,      MsgHandler(this, &Window::OnPaint));
        m_WindowBase.AppendMsgHandler(WM_LBUTTONUP,  MsgHandler(this, &Window::OnLButtonUp));
        m_WindowBase.AppendMsgHandler(WM_RBUTTONUP,  MsgHandler(this, &Window::OnRButtonUp));
        m_WindowBase.AppendMsgHandler(WM_DESTROY,    MsgHandler(this, &Window::OnDestroy));
    }
};

這個(gè)問題，不知道各位有沒有什么思考？

還有一個(gè)問題是，接下去要不要將 WPARAM 和 LPARAM 的含義徹底解析掉，搞成一系列 PaintParam、EraseBackgroundParam、LButtonUpParam、RButtonUpParam，DestroyParam，讓使用的時(shí)候與原始消息參數(shù)徹底隔離呢？

最后一步，雖說(shuō)是體力活，但這跟最終的應(yīng)用場(chǎng)合密切相關(guān)，需要提供怎么樣的功能是一件需要考量的事。

目前走在第二步，所以下面的兩個(gè)問題思考得不多。求經(jīng)驗(yàn)，求意見。