转载请说明原出处，谢谢~~
看到群里朋友有人讨论WTL中的thunk技术，让我联想到了duilib的类似技术。这些技术都是为了解决c++封装的窗体类与窗体句柄的关联问题。
这里是三篇关于thunk技术的博客，不懂的朋友可以先看一下：
WTL学习之旅(三)WTL中 Thunk技术本质(含代码)
深入剖析WTL—WTL框架窗口分析 （5）
学习下 WTL 的 thunk
我这里直接引用其他博客的一部分文字来说明窗体类与窗体句柄关联的重要性和相关的问题，然后说明一下duilib中的解决方法：
-----------------------------------------------------引用开始------------------------------------------------------------------
由于 C++ 成员函数的调用机制问题，对C语言回调函数的 C++ 封装是件比较棘手的事。为了保持C++对象的独立性，理想情况是将回调函数设置到成员函数，而一般的回调函数格式通常是普通的C函数，尤其是 Windows API 中的。好在有些回调函数中留出了一个额外参数，这样便可以由这个通道将 this 指针传入。比如线程函数的定义为：
typedef DWORD (WINAPI *PTHREAD_START_ROUTINE)(
LPVOID lpThreadParameter
);
typedef PTHREAD_START_ROUTINE LPTHREAD_START_ROUTINE;
这样，当我们实现线程类的时候，就可以：
class Thread
{
private:
HANDLE m_hThread;
public:
BOOL Create()
{
m_hThread = CreateThread(NULL, 0, StaticThreadProc, (LPVOID)this, 0, NULL);
return m_hThread != NULL;
}
private:
DWORD WINAPI ThreadProc()
{
// TODO
return 0;
}
private:
static DWORD WINAPI StaticThreadProc(LPVOID lpThreadParameter)
{
((Thread *)lpThreadParameter)->ThreadProc();
}
};
不过，这样，成员函数 ThreadProc() 便丧失了一个参数，这通常无伤大雅，任何原本需要从参数传入的信息都可以作为成员变量让 ThreadProc 来读写。如果一定有些什么是非从参数传入不可的，那也可以，一种做法，创建线程的时候传入一个包含 this 指针信息的结构。第二种做法，对该 class 作单例限制——如果现实情况允许的话。
所以，有额外参数的回调函数都好处理。不幸的是，Windows 的窗口回调函数没有这样一个额外参数：
typedef LRESULT (CALLBACK* WNDPROC)(HWND, UINT, WPARAM, LPARAM);
这使得对窗口的 C++ 封装变得困难。为了解决这个问题，一个很自然的想法是，维护一份全局的窗口句柄到窗口类的对应关系，如：
#include <map>
class Window
{
public:
Window();
~Window();
public:
BOOL Create();
protected:
LRESULT WndProc(UINT message, WPARAM wParam, LPARAM lParam);
protected:
HWND m_hWnd;
protected:
static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam);
static std::map<HWND, Window *> m_sWindows;
};
在 Create 的时候，指定 StaticWndProc 为窗口回调函数，并将 hWnd 与 this 存入 m_sWindows：
BOOL Window::Create()
{
LPCTSTR lpszClassName = _T("ClassName");
HINSTANCE hInstance = GetModuleHandle(NULL);
WNDCLASSEX wcex = { sizeof(WNDCLASSEX) };
wcex.lpfnWndProc = StaticWndProc;
wcex.hInstance = hInstance;
wcex.lpszClassName = lpszClassName;
RegisterClassEx(&wcex);
m_hWnd = CreateWindow(lpszClassName, NULL, WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);
if (m_hWnd == NULL)
{
return FALSE;
}
m_sWindows.insert(std::make_pair(m_hWnd, this));
ShowWindow(m_hWnd, SW_SHOW);
UpdateWindow(m_hWnd);
return TRUE;
}
在 StaticWindowProc 中，由 hWnd 找到 this，然后转发给成员函数：
LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
std::map<HWND, Window *>::iterator it = m_sWindows.find(hWnd);
assert(it != m_sWindows.end() && it->second != NULL);
return it->second->WndProc(message, wParam, lParam);
}
（m_sWindows 的多线程保护略过，下同）
据说 MFC 采用的就是类似的做法。缺点是，每次 StaticWndProc 都要从 m_sWindows 中去找 this。由于窗口类一般会保存窗口句柄，回调函数里的 hWnd 就没多大作用了，如果这个 hWnd 能够被用来存 this 指针就好了，那么就能写成这样：
LRESULT CALLBACK Window::StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
return ((Window *)hWnd)->WndProc(message, wParam, lParam);
}
这样看上去就爽多了。传说中 WTL 所采取的 thunk 技术就是这么干的。
-----------------------------------------------------引用结束------------------------------------------------------------------
可以看到，封装一个窗体类，让这个类与他生成的窗体关联，并且去处理这个窗体的窗体消息并不是简单的事，MFC和WTL都有自己的方法来解决。而duilib库的最初作者更是对MFC、WTL等库相当熟悉，我这里说明一下duilib解决这个问题的办法，个人觉得duilib的这个办法要比thunk简单好用很多。
我们使用duilib创建一个窗体，会调用窗体基类CWindowWnd类的Create函数，相关代码如下：
- HWND CWindowWnd::Create(HWND hwndParent, LPCTSTR pstrName, DWORD dwStyle, DWORD dwExStyle, int x, int y, int cx, int cy, HMENU hMenu)
- {
- if( GetSuperClassName() != NULL && !RegisterSuperclass() ) return NULL;
- if( GetSuperClassName() == NULL && !RegisterWindowClass() ) return NULL;
- m_hWnd = ::CreateWindowEx(dwExStyle, GetWindowClassName(), pstrName, dwStyle, x, y, cx, cy, hwndParent, hMenu, CPaintManagerUI::GetInstance(), this);
- ASSERT(m_hWnd!=NULL);
- return m_hWnd;
- }
可以看到最终使用了CreateWindowEx函数来创建窗体，而这里的最后一个参数相当关键，这里是 CreateWindowEx函数让我们自己传递的一个自定义数据，可以看到duilib中把自己类的this传了进去！这就是duilib解决窗体类与窗体句柄关联的起点了。
接着当窗体开始建立时就会发送消息到相关的消息处理回调函数，duilib中对应的是__WndProc函数，函数代码如下：
- LRESULT CALLBACK CWindowWnd::__WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
- {
- CWindowWnd* pThis = NULL;
- if( uMsg == WM_NCCREATE ) {
- LPCREATESTRUCT lpcs = reinterpret_cast<LPCREATESTRUCT>(lParam);
- pThis = static_cast<CWindowWnd*>(lpcs->lpCreateParams);
- pThis->m_hWnd = hWnd;
- ::SetWindowLongPtr(hWnd, GWLP_USERDATA, reinterpret_cast<LPARAM>(pThis));
- }
- else {
- pThis = reinterpret_cast<CWindowWnd*>(::GetWindowLongPtr(hWnd, GWLP_USERDATA));
- if( uMsg == WM_NCDESTROY && pThis != NULL ) {
- LRESULT lRes = ::CallWindowProc(pThis->m_OldWndProc, hWnd, uMsg, wParam, lParam);
- ::SetWindowLongPtr(pThis->m_hWnd, GWLP_USERDATA, 0L);
- if( pThis->m_bSubclassed ) pThis->Unsubclass();
- pThis->m_hWnd = NULL;
- pThis->OnFinalMessage(hWnd);
- return lRes;
- }
- }
- if( pThis != NULL ) {
- return pThis->HandleMessage(uMsg, wParam, lParam);
- }
- else {
- return ::DefWindowProc(hWnd, uMsg, wParam, lParam);
- }
- }
我们通常会理解在窗口创建时发出消息WM_CREATE，但是在 WM_CREATE 消息之前还有一个消息是被发出的，那就是WM_NCCREATE消息，可以看到在duilib处理函数中围绕这个消息做了文章。先看看这个消息的介绍：
Parameters
-
wParam
-
This parameter is not used.
lParam
-
A pointer to the CREATESTRUCT structure that contains information about the window being created. The members of CREATESTRUCT are identical to the parameters of the CreateWindowEx function.
这个消息的lParam参数是关键，这个参数是传进来CREATESTRUCT结构，这个结构体介绍如下：
CREATESTRUCT 结构定义初始化参数传递给应用程序的窗口过程。
typedef struct tagCREATESTRUCT {
LPVOID lpCreateParams;
HANDLE hInstance;
HMENU hMenu;
HWND hwndParent;
int cy;
int cx;
int y;
int x;
LONG style;
LPCSTR lpszName;
LPCSTR lpszClass;
DWORD dwExStyle;
} CREATESTRUCT;
如果文章中有什么错误，可以联系我或者留言
Redrain QQ：491646717 2014.9.19
扫一扫
374
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
