DuiLib 消息机制剖析
2015-06-29 10:13
295 查看
有一篇新的:http://blog.163.com/hao_dsliu/blog/static/1315789082014101913351223/
其消息处理架构较为灵活,基本上在消息能过滤到的地方,都给出了扩展接口。
看了DuiLib入门教程后,对消息机制的处理有些模糊,为了屏蔽Esc按键,都花了大半天的时间。究其原因,是因为对DuiLib消息过滤不了解。这篇教程,可能不适合刚刚接触DuiLib没两天的人看。至少你应该看过一些代码,但可能没看懂,那么这篇文章可能会给你指点迷津。
Win32消息路由如下:
消息产生。
系统将消息排列到其应该排放的线程消息队列中。
线程中的消息循环调用GetMessage(or PeekMessage)获取消息。
传送消息TranslateMessage and DispatchMessage to 窗口过程(Windows procedure)。
在窗口过程里进行消息处理
我们看到消息经过几个步骤,DuiLib架构可以让你在某些步骤间进行消息过滤。首先,第1、2和3步骤,DuiLib并不关心。DuiLib对消息处理集中在CPaintManagerUI类中。DuiLib在发送窗口过程前后进行了消息过滤。
DuiLib的消息渠,也就是所谓的消息循环在CPaintManagerUI::MessageLoop()或者CWindowWnd::ShowModal()中实现。俩套代码的核心基本一致,以MessageLoop为例:
void CPaintManagerUI::MessageLoop()
{
MSG msg = { 0 };
while( ::GetMessage(&msg, NULL,
0, 0) ) {
// CPaintManagerUI::TranslateMessage进行消息过滤
if( !CPaintManagerUI::TranslateMessage(&msg)
) {
::TranslateMessage(&msg);
try{
::DispatchMessage(&msg);
} catch(...) {
DUITRACE(_T("EXCEPTION: %s(%d)\n"), __FILET__, __LINE__);
#ifdef _DEBUG
throw "CPaintManagerUI::MessageLoop";
#endif
}
}
}
}
3和4之间,DuiLib调用CPaintManagerUI::TranslateMessage做了过滤,类似MFC的PreTranlateMessage。
想象一下,如果不使用这套消息循环代码,我们如何能做到在消息发送到窗口过程前进行常规过滤(Hook等拦截技术除外)?答案肯定是做不到。因为那段循环代码你是无法控制的。CPaintManagerUI::TranslateMessage将无法被调用,所以,可以看到DuiLib中几乎所有的demo都调用了这俩个消息循环函数。下面是TranslateMessage代码:
bool CPaintManagerUI::TranslateMessage(const LPMSG pMsg)
{
// Pretranslate Message takes care of system-wide messages, such as
// tabbing and shortcut key-combos. We'll look for all messages for
// each window and any child control attached.
UINT uStyle = GetWindowStyle(pMsg->hwnd);
UINT uChildRes = uStyle & WS_CHILD;
LRESULT lRes = 0;
if (uChildRes != 0) // 判断子窗口还是父窗口
{
HWND hWndParent = ::GetParent(pMsg->hwnd);
for( int i = 0; i < m_aPreMessages.GetSize(); i++
)
{
CPaintManagerUI* pT = static_cast<CPaintManagerUI*>(m_aPreMessages[i]);
HWND hTempParent = hWndParent;
while(hTempParent)
{
if(pMsg->hwnd == pT->GetPaintWindow()
|| hTempParent == pT->GetPaintWindow())
{
if (pT->TranslateAccelerator(pMsg))
return true;
// 这里进行消息过滤
if( pT->PreMessageHandler(pMsg->message, pMsg->wParam,pMsg->lParam, lRes)
)
return true;
return false;
}
hTempParent = GetParent(hTempParent);
}
}
}
else
{
for( int i = 0; i < m_aPreMessages.GetSize(); i++
)
{
CPaintManagerUI* pT = static_cast<CPaintManagerUI*>(m_aPreMessages[i]);
if(pMsg->hwnd == pT->GetPaintWindow())
{
if (pT->TranslateAccelerator(pMsg))
return true;
if( pT->PreMessageHandler(pMsg->message, pMsg->wParam, pMsg->lParam, lRes)
)
return true;
return false;
}
}
}
return false;
}
bool CPaintManagerUI::PreMessageHandler(UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT&/*lRes*/)
{
for( int i = 0; i < m_aPreMessageFilters.GetSize(); i++
)
{
bool bHandled = false;
LRESULT lResult = static_cast<IMessageFilterUI*>(m_aPreMessageFilters[i])->MessageHandler(uMsg, wParam, lParam, bHandled);
// 这里调用接口 IMessageFilterUI::MessageHandler来进行消息过滤
if( bHandled ) {
return true;
}
}
…… ……
return false;
}
在发送到窗口过程前,有一个过滤接口:IMessageFilterUI,此接口只有一个成员:MessageHandler,我们的窗口类要提前过滤消息,只要实现这个IMessageFilterUI,调用CPaintManagerUI:: AddPreMessageFilter,将我们的窗口类实例指针添加到m_aPreMessageFilters
array 中。当消息到达窗口过程之前,就会会先调用我们的窗口类的成员函数:MessageHandler。
下面是AddPreMessageFilter代码:
bool CPaintManagerUI::AddPreMessageFilter(IMessageFilterUI* pFilter)
{
// 将实现好的接口实例,保存到数组 m_aPreMessageFilters 中。
ASSERT(m_aPreMessageFilters.Find(pFilter)<0);
return m_aPreMessageFilters.Add(pFilter);
}
我们从函数CPaintManagerUI::TranslateMessage代码中能够看到,这个过滤是在大循环:
for( int i = 0; i < m_aPreMessages.GetSize(); i++
)
中被调用的。如果m_aPreMessages.GetSize()为0,也就不会调用过滤函数。从代码中追溯其定义:
static CStdPtrArray m_aPreMessages;
是个静态变量,MessageLoop,TranslateMessage等也都是静态函数。其值在CPaintManagerUI::Init中被初始化:
void CPaintManagerUI::Init(HWND hWnd)
{
ASSERT(::IsWindow(hWnd));
// Remember the window context we came from
m_hWndPaint = hWnd;
m_hDcPaint = ::GetDC(hWnd);
// We'll want to filter messages globally too
m_aPreMessages.Add(this);
}
看来,m_aPreMessages存储的类型为CPaintManagerUI* ,也就说,这个静态成员数组里,存储了当前进程中所有的CPaintManagerUI实例指针,所以,如果有多个CPaintManagerUI实例,也不会存在过滤问题,互不干扰,都能各自过滤。当然m_aPreMessages不止用在消息循环中,也有别的用处。我觉得这个名字起得有点诡异。
。然后,我们创建窗口先实例化窗口,然后带调用这俩个基类的Create函数,创建窗口,其内部注册了窗口过程:
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);
}
}
里面,主要做了一些转换,细节自行研究,最终,他会调用pThis->HandleMessage(uMsg, wParam, lParam);。也即是说,HandleMessage相当于一个窗口过程(虽然它不是,但功能类似)。他是CWindowWnd的虚函数:
virtual LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam);
所以,如果我们的窗口类实现了HandleMessage,就相当于再次过滤了窗口过程,HandleMessage代码框架如下:
LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam)
{
if( uMsg == WM_XXX ) {
… …
return 0;
}
else if( uMsg == WM_XXX) {
… …
return 1;
}
LRESULT lRes = 0;
if( m_pm.MessageHandler(uMsg, wParam, lParam, lRes)
) //CPaintManagerUI::MessageHandler
return lRes;
return CWindowWnd::HandleMessage(uMsg, wParam, lParam);
// 调用父类HandleMessage
}
在注意:CPaintManagerUI::MessageHandler,他们的名称为MessageHandler,而不是HandleMessage。
没有特殊需求,一定要调用此函数,此函数处理了绝大部分常用的消息响应。而且如果你要响应Notify事件,不调用此函数将无法响应,后面会介绍。
好现在我们已经知道,俩个地方可以截获消息:
实现IMessageFilterUI接口,调用CPaintManagerUI:: AddPreMessageFilter,进行消息发送到窗口过程前的过滤。
重载HandleMessage函数,当消息发送到窗口过程中时,最先进行过滤。
下面继续看看void Notify(TNotifyUI& msg)是如何响应的。我们的窗口继承于INotifyUI接口,就必须实现此函数:
class INotifyUI
{
public:
virtual void Notify(TNotifyUI& msg)
= 0;
};
上面我说了,在我们的HandleMessage要调用CPaintManagerUI::MessageHandler来进行后续处理。下面是一个代码片段:
bool CPaintManagerUI::MessageHandler(UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT& lRes)
{
… …
TNotifyUI* pMsg = NULL;
while( pMsg = static_cast<TNotifyUI*>(m_aAsyncNotify.GetAt(0))
) {
m_aAsyncNotify.Remove(0);
if( pMsg->pSender != NULL )
{
if( pMsg->pSender->OnNotify ) pMsg->pSender->OnNotify(pMsg);
}
// 先看这里,其它代码先忽略;我们看到一个转换操作static_cast<INotifyUI*>
for( int j = 0; j < m_aNotifiers.GetSize(); j++
) {
static_cast<INotifyUI*>(m_aNotifiers[j])->Notify(*pMsg);
}
delete pMsg;
}
// Cycle through listeners
for( int i = 0; i < m_aMessageFilters.GetSize(); i++
)
{
bool bHandled = false;
LRESULT lResult = static_cast<IMessageFilterUI*>(m_aMessageFilters[i])->MessageHandler(uMsg, wParam, lParam, bHandled);
if( bHandled ) {
lRes = lResult;
return true;
}
}
… …
}
定义为CStdPtrArray m_aNotifiers;数组,目前还看不出其指向的实际类型。看看,什么时候给该数组添加成员:
bool CPaintManagerUI::AddNotifier(INotifyUI* pNotifier)
{
ASSERT(m_aNotifiers.Find(pNotifier)<0);
return m_aNotifiers.Add(pNotifier);
}
不错,正是AddNotifier,类型也有了:INotifyUI。所以,入门教程里会在响应WM_CREATE消息的时候,调用AddNotifier(this),将自身加入数组中,然后在CPaintManagerUI::MessageHandler就能枚举调用。由于AddNotifer的参数为INotifyUI*,所以,我们要实现此接口。
所以,当HandleMessage函数被调用后,紧接着会调用我们的Notify函数。如果你没有对消息过滤的特殊需求,实现INotifyUI即可,在Notify函数中处理消息响应。
上面的Notify调用,是响应系统产生的消息。程序本身也能手动产生,其函数为:
void CPaintManagerUI::SendNotify(TNotifyUI& Msg, bool bAsync /*=
false*/)
DuiLib将发送的Notify消息分为了同步和异步消息。同步就是立即调用,异步就是先放到队列中,下次再处理。(类似PostMessage)。
void CPaintManagerUI::SendNotify(TNotifyUI& Msg, bool bAsync /*=
false*/)
{
… …
if( !bAsync ) {
// Send to all listeners
// 同步调用OnNotify,注意不是Notify
if( Msg.pSender != NULL )
{
if( Msg.pSender->OnNotify ) Msg.pSender->OnNotify(&Msg);
}
// 还会再次通知所有注册了INotifyUI的窗口。
for( int i = 0; i < m_aNotifiers.GetSize(); i++
) {
static_cast<INotifyUI*>(m_aNotifiers[i])->Notify(Msg);
}
}
else {
// 异步调用,添加到m_aAsyncNotify array中
TNotifyUI *pMsg = new TNotifyUI;
pMsg->pSender = Msg.pSender;
pMsg->sType = Msg.sType;
pMsg->wParam = Msg.wParam;
pMsg->lParam = Msg.lParam;
pMsg->ptMouse = Msg.ptMouse;
pMsg->dwTimestamp = Msg.dwTimestamp;
m_aAsyncNotify.Add(pMsg);
}
}
我们CPaintManagerUI::MessageHandler在开始处发现一些代码:
TNotifyUI* pMsg = NULL;
while( pMsg = static_cast<TNotifyUI*>(m_aAsyncNotify.GetAt(0))
) {
m_aAsyncNotify.Remove(0);
if( pMsg->pSender != NULL ) {
if( pMsg->pSender->OnNotify ) pMsg->pSender->OnNotify(pMsg);
}
可以看到MessageHandler首先从异步队列中一个消息并调用OnNotify。OnNotify和上面的Notify不一样哦。
OnNotify是响应消息的另外一种方式。它的定义为:
CEventSource OnNotify;
属于CControlUI类。重载了一些运算符,如 operator();要让控件响应手动发送(SendNotify)的消息,就要给控件的OnNotify,添加消息代理。在DuiLib的TestApp1中的OnPrepare函数里,有:
CSliderUI* pSilder = static_cast<CSliderUI*>(m_pm.FindControl(_T("alpha_controlor")));
if( pSilder ) pSilder->OnNotify += MakeDelegate(this,
&CFrameWindowWnd::OnAlphaChanged);
至于消息代码的代码,我就不展示了,这里简单说明,就是将类成员函数,作为回调函数,加入到OnNotify中,然后调用pMsg->pSender->OnNotify(pMsg)的时候,循环调用所有的类函数,实现通知的效果。
这段代理代码处理的很巧妙,结婚多态和模板,能将任何类成员函数作为回调函数。
查阅CSliderUI代码,发现他在自身的DoEvent函数内调用了诸如:
m_pManager->SendNotify(this, DUI_MSGTYPE_VALUECHANGED);
类似的代码,调用它,我们就会得到通知。
现在,又多了两种消息处理的方式:
实现INotifyUI,调用CPaintManagerUI::AddNotifier,将自身加入Notifier队列。
添加消息代理(其实就是将成员函数最为回到函数加入),MakeDelegate(this,
&CFrameWindowWnd::OnAlphaChanged);,当程序某个地方调用了CPaintManagerUI::SendNotify,并且Msg.pSender正好是this,我们的类成员回调函数将被调用。
搜寻CPaintManagerUI代码,我们发现还有一些消息过滤再里面:
bool CPaintManagerUI::AddMessageFilter(IMessageFilterUI* pFilter)
{
ASSERT(m_aMessageFilters.Find(pFilter)<0);
return m_aMessageFilters.Add(pFilter);
}
m_aMessageFilters也是IMessageFilterUI array,和m_aPreMessageFilters类似。
上面我们介绍的是CPaintManagerUI::AddPreMessageFilter,那这个又是在哪儿做的过滤?
还是CPaintManagerUI::MessageHandler中:
……
// Cycle through listeners
for( int i = 0; i < m_aMessageFilters.GetSize(); i++
)
{
bool bHandled = false;
LRESULT lResult = static_cast<IMessageFilterUI*>(m_aMessageFilters[i])->MessageHandler(uMsg, wParam, lParam, bHandled);
if( bHandled ) {
lRes = lResult;
return true;
}
}
… …
这个片段是在,异步OnNotify和Nofity消息响应,被调用后。才被调用的,优先级也就是最低。但它始终会被调用,因为异步OnNotify和Nofity消息响应没有返回值,不会因为消息已经被处理,而直接退出。DuiLib再次给用户一个处理消息的机会。用户可以选择将bHandled设置为True,从而终止消息继续传递。我觉得,这个通常是为了弥补OnNotify和Nofity没有返回值的问题,在m_aMessageFilters做集中处理。
处理完所有的消息响应后,如果消息没有被截断,CPaintManagerUI::MessageHandler继续处理大多数默认的消息,它会处理在其管理范围中的所有控件的大多数消息和事件等。
总结,DuiLib消息响应方式:
实现IMessageFilterUI接口,调用CPaintManagerUI:: AddPreMessageFilter,进行消息发送到窗口过程前的过滤。
重载HandleMessage函数,当消息发送到窗口过程中时,最先进行过滤。
实现INotifyUI,调用CPaintManagerUI::AddNotifier,将自身加入Notifier队列。
添加消息代理(其实就是将成员函数最为回到函数加入),MakeDelegate(this,
&CFrameWindowWnd::OnAlphaChanged);,当程序某个地方调用了CPaintManagerUI::SendNotify,并且Msg.pSender正好是this,我们的类成员回调函数将被调用。
话说DuiLib做界面,真是太方便了。我花了三天时间,从零开始学习,搞出了一个软键盘,发现逻辑上的代码量大大简化了。同样用MFC写,我的同事花了一周的时间,来调整布局和代码逻辑,里面写死了一堆要定位的坐标相关的值,如读天书一般,而且还很丑陋,再看看DuiLib做的软键盘,完全没有可比性。不过DuiLib的工具类如CDuiString等,会有一些bug。还是得继续完善。
其消息处理架构较为灵活,基本上在消息能过滤到的地方,都给出了扩展接口。
看了DuiLib入门教程后,对消息机制的处理有些模糊,为了屏蔽Esc按键,都花了大半天的时间。究其原因,是因为对DuiLib消息过滤不了解。这篇教程,可能不适合刚刚接触DuiLib没两天的人看。至少你应该看过一些代码,但可能没看懂,那么这篇文章可能会给你指点迷津。
Win32消息路由如下:
消息产生。
系统将消息排列到其应该排放的线程消息队列中。
线程中的消息循环调用GetMessage(or PeekMessage)获取消息。
传送消息TranslateMessage and DispatchMessage to 窗口过程(Windows procedure)。
在窗口过程里进行消息处理
我们看到消息经过几个步骤,DuiLib架构可以让你在某些步骤间进行消息过滤。首先,第1、2和3步骤,DuiLib并不关心。DuiLib对消息处理集中在CPaintManagerUI类中。DuiLib在发送窗口过程前后进行了消息过滤。
DuiLib的消息渠,也就是所谓的消息循环在CPaintManagerUI::MessageLoop()或者CWindowWnd::ShowModal()中实现。俩套代码的核心基本一致,以MessageLoop为例:
void CPaintManagerUI::MessageLoop()
{
MSG msg = { 0 };
while( ::GetMessage(&msg, NULL,
0, 0) ) {
// CPaintManagerUI::TranslateMessage进行消息过滤
if( !CPaintManagerUI::TranslateMessage(&msg)
) {
::TranslateMessage(&msg);
try{
::DispatchMessage(&msg);
} catch(...) {
DUITRACE(_T("EXCEPTION: %s(%d)\n"), __FILET__, __LINE__);
#ifdef _DEBUG
throw "CPaintManagerUI::MessageLoop";
#endif
}
}
}
}
3和4之间,DuiLib调用CPaintManagerUI::TranslateMessage做了过滤,类似MFC的PreTranlateMessage。
想象一下,如果不使用这套消息循环代码,我们如何能做到在消息发送到窗口过程前进行常规过滤(Hook等拦截技术除外)?答案肯定是做不到。因为那段循环代码你是无法控制的。CPaintManagerUI::TranslateMessage将无法被调用,所以,可以看到DuiLib中几乎所有的demo都调用了这俩个消息循环函数。下面是TranslateMessage代码:
bool CPaintManagerUI::TranslateMessage(const LPMSG pMsg)
{
// Pretranslate Message takes care of system-wide messages, such as
// tabbing and shortcut key-combos. We'll look for all messages for
// each window and any child control attached.
UINT uStyle = GetWindowStyle(pMsg->hwnd);
UINT uChildRes = uStyle & WS_CHILD;
LRESULT lRes = 0;
if (uChildRes != 0) // 判断子窗口还是父窗口
{
HWND hWndParent = ::GetParent(pMsg->hwnd);
for( int i = 0; i < m_aPreMessages.GetSize(); i++
)
{
CPaintManagerUI* pT = static_cast<CPaintManagerUI*>(m_aPreMessages[i]);
HWND hTempParent = hWndParent;
while(hTempParent)
{
if(pMsg->hwnd == pT->GetPaintWindow()
|| hTempParent == pT->GetPaintWindow())
{
if (pT->TranslateAccelerator(pMsg))
return true;
// 这里进行消息过滤
if( pT->PreMessageHandler(pMsg->message, pMsg->wParam,pMsg->lParam, lRes)
)
return true;
return false;
}
hTempParent = GetParent(hTempParent);
}
}
}
else
{
for( int i = 0; i < m_aPreMessages.GetSize(); i++
)
{
CPaintManagerUI* pT = static_cast<CPaintManagerUI*>(m_aPreMessages[i]);
if(pMsg->hwnd == pT->GetPaintWindow())
{
if (pT->TranslateAccelerator(pMsg))
return true;
if( pT->PreMessageHandler(pMsg->message, pMsg->wParam, pMsg->lParam, lRes)
)
return true;
return false;
}
}
}
return false;
}
bool CPaintManagerUI::PreMessageHandler(UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT&/*lRes*/)
{
for( int i = 0; i < m_aPreMessageFilters.GetSize(); i++
)
{
bool bHandled = false;
LRESULT lResult = static_cast<IMessageFilterUI*>(m_aPreMessageFilters[i])->MessageHandler(uMsg, wParam, lParam, bHandled);
// 这里调用接口 IMessageFilterUI::MessageHandler来进行消息过滤
if( bHandled ) {
return true;
}
}
…… ……
return false;
}
在发送到窗口过程前,有一个过滤接口:IMessageFilterUI,此接口只有一个成员:MessageHandler,我们的窗口类要提前过滤消息,只要实现这个IMessageFilterUI,调用CPaintManagerUI:: AddPreMessageFilter,将我们的窗口类实例指针添加到m_aPreMessageFilters
array 中。当消息到达窗口过程之前,就会会先调用我们的窗口类的成员函数:MessageHandler。
下面是AddPreMessageFilter代码:
bool CPaintManagerUI::AddPreMessageFilter(IMessageFilterUI* pFilter)
{
// 将实现好的接口实例,保存到数组 m_aPreMessageFilters 中。
ASSERT(m_aPreMessageFilters.Find(pFilter)<0);
return m_aPreMessageFilters.Add(pFilter);
}
我们从函数CPaintManagerUI::TranslateMessage代码中能够看到,这个过滤是在大循环:
for( int i = 0; i < m_aPreMessages.GetSize(); i++
)
中被调用的。如果m_aPreMessages.GetSize()为0,也就不会调用过滤函数。从代码中追溯其定义:
static CStdPtrArray m_aPreMessages;
是个静态变量,MessageLoop,TranslateMessage等也都是静态函数。其值在CPaintManagerUI::Init中被初始化:
void CPaintManagerUI::Init(HWND hWnd)
{
ASSERT(::IsWindow(hWnd));
// Remember the window context we came from
m_hWndPaint = hWnd;
m_hDcPaint = ::GetDC(hWnd);
// We'll want to filter messages globally too
m_aPreMessages.Add(this);
}
看来,m_aPreMessages存储的类型为CPaintManagerUI* ,也就说,这个静态成员数组里,存储了当前进程中所有的CPaintManagerUI实例指针,所以,如果有多个CPaintManagerUI实例,也不会存在过滤问题,互不干扰,都能各自过滤。当然m_aPreMessages不止用在消息循环中,也有别的用处。我觉得这个名字起得有点诡异。
。然后,我们创建窗口先实例化窗口,然后带调用这俩个基类的Create函数,创建窗口,其内部注册了窗口过程:
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);
}
}
里面,主要做了一些转换,细节自行研究,最终,他会调用pThis->HandleMessage(uMsg, wParam, lParam);。也即是说,HandleMessage相当于一个窗口过程(虽然它不是,但功能类似)。他是CWindowWnd的虚函数:
virtual LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam);
所以,如果我们的窗口类实现了HandleMessage,就相当于再次过滤了窗口过程,HandleMessage代码框架如下:
LRESULT HandleMessage(UINT uMsg, WPARAM wParam, LPARAM lParam)
{
if( uMsg == WM_XXX ) {
… …
return 0;
}
else if( uMsg == WM_XXX) {
… …
return 1;
}
LRESULT lRes = 0;
if( m_pm.MessageHandler(uMsg, wParam, lParam, lRes)
) //CPaintManagerUI::MessageHandler
return lRes;
return CWindowWnd::HandleMessage(uMsg, wParam, lParam);
// 调用父类HandleMessage
}
在注意:CPaintManagerUI::MessageHandler,他们的名称为MessageHandler,而不是HandleMessage。
没有特殊需求,一定要调用此函数,此函数处理了绝大部分常用的消息响应。而且如果你要响应Notify事件,不调用此函数将无法响应,后面会介绍。
好现在我们已经知道,俩个地方可以截获消息:
实现IMessageFilterUI接口,调用CPaintManagerUI:: AddPreMessageFilter,进行消息发送到窗口过程前的过滤。
重载HandleMessage函数,当消息发送到窗口过程中时,最先进行过滤。
下面继续看看void Notify(TNotifyUI& msg)是如何响应的。我们的窗口继承于INotifyUI接口,就必须实现此函数:
class INotifyUI
{
public:
virtual void Notify(TNotifyUI& msg)
= 0;
};
上面我说了,在我们的HandleMessage要调用CPaintManagerUI::MessageHandler来进行后续处理。下面是一个代码片段:
bool CPaintManagerUI::MessageHandler(UINT uMsg, WPARAM wParam, LPARAM lParam, LRESULT& lRes)
{
… …
TNotifyUI* pMsg = NULL;
while( pMsg = static_cast<TNotifyUI*>(m_aAsyncNotify.GetAt(0))
) {
m_aAsyncNotify.Remove(0);
if( pMsg->pSender != NULL )
{
if( pMsg->pSender->OnNotify ) pMsg->pSender->OnNotify(pMsg);
}
// 先看这里,其它代码先忽略;我们看到一个转换操作static_cast<INotifyUI*>
for( int j = 0; j < m_aNotifiers.GetSize(); j++
) {
static_cast<INotifyUI*>(m_aNotifiers[j])->Notify(*pMsg);
}
delete pMsg;
}
// Cycle through listeners
for( int i = 0; i < m_aMessageFilters.GetSize(); i++
)
{
bool bHandled = false;
LRESULT lResult = static_cast<IMessageFilterUI*>(m_aMessageFilters[i])->MessageHandler(uMsg, wParam, lParam, bHandled);
if( bHandled ) {
lRes = lResult;
return true;
}
}
… …
}
定义为CStdPtrArray m_aNotifiers;数组,目前还看不出其指向的实际类型。看看,什么时候给该数组添加成员:
bool CPaintManagerUI::AddNotifier(INotifyUI* pNotifier)
{
ASSERT(m_aNotifiers.Find(pNotifier)<0);
return m_aNotifiers.Add(pNotifier);
}
不错,正是AddNotifier,类型也有了:INotifyUI。所以,入门教程里会在响应WM_CREATE消息的时候,调用AddNotifier(this),将自身加入数组中,然后在CPaintManagerUI::MessageHandler就能枚举调用。由于AddNotifer的参数为INotifyUI*,所以,我们要实现此接口。
所以,当HandleMessage函数被调用后,紧接着会调用我们的Notify函数。如果你没有对消息过滤的特殊需求,实现INotifyUI即可,在Notify函数中处理消息响应。
上面的Notify调用,是响应系统产生的消息。程序本身也能手动产生,其函数为:
void CPaintManagerUI::SendNotify(TNotifyUI& Msg, bool bAsync /*=
false*/)
DuiLib将发送的Notify消息分为了同步和异步消息。同步就是立即调用,异步就是先放到队列中,下次再处理。(类似PostMessage)。
void CPaintManagerUI::SendNotify(TNotifyUI& Msg, bool bAsync /*=
false*/)
{
… …
if( !bAsync ) {
// Send to all listeners
// 同步调用OnNotify,注意不是Notify
if( Msg.pSender != NULL )
{
if( Msg.pSender->OnNotify ) Msg.pSender->OnNotify(&Msg);
}
// 还会再次通知所有注册了INotifyUI的窗口。
for( int i = 0; i < m_aNotifiers.GetSize(); i++
) {
static_cast<INotifyUI*>(m_aNotifiers[i])->Notify(Msg);
}
}
else {
// 异步调用,添加到m_aAsyncNotify array中
TNotifyUI *pMsg = new TNotifyUI;
pMsg->pSender = Msg.pSender;
pMsg->sType = Msg.sType;
pMsg->wParam = Msg.wParam;
pMsg->lParam = Msg.lParam;
pMsg->ptMouse = Msg.ptMouse;
pMsg->dwTimestamp = Msg.dwTimestamp;
m_aAsyncNotify.Add(pMsg);
}
}
我们CPaintManagerUI::MessageHandler在开始处发现一些代码:
TNotifyUI* pMsg = NULL;
while( pMsg = static_cast<TNotifyUI*>(m_aAsyncNotify.GetAt(0))
) {
m_aAsyncNotify.Remove(0);
if( pMsg->pSender != NULL ) {
if( pMsg->pSender->OnNotify ) pMsg->pSender->OnNotify(pMsg);
}
可以看到MessageHandler首先从异步队列中一个消息并调用OnNotify。OnNotify和上面的Notify不一样哦。
OnNotify是响应消息的另外一种方式。它的定义为:
CEventSource OnNotify;
属于CControlUI类。重载了一些运算符,如 operator();要让控件响应手动发送(SendNotify)的消息,就要给控件的OnNotify,添加消息代理。在DuiLib的TestApp1中的OnPrepare函数里,有:
CSliderUI* pSilder = static_cast<CSliderUI*>(m_pm.FindControl(_T("alpha_controlor")));
if( pSilder ) pSilder->OnNotify += MakeDelegate(this,
&CFrameWindowWnd::OnAlphaChanged);
至于消息代码的代码,我就不展示了,这里简单说明,就是将类成员函数,作为回调函数,加入到OnNotify中,然后调用pMsg->pSender->OnNotify(pMsg)的时候,循环调用所有的类函数,实现通知的效果。
这段代理代码处理的很巧妙,结婚多态和模板,能将任何类成员函数作为回调函数。
查阅CSliderUI代码,发现他在自身的DoEvent函数内调用了诸如:
m_pManager->SendNotify(this, DUI_MSGTYPE_VALUECHANGED);
类似的代码,调用它,我们就会得到通知。
现在,又多了两种消息处理的方式:
实现INotifyUI,调用CPaintManagerUI::AddNotifier,将自身加入Notifier队列。
添加消息代理(其实就是将成员函数最为回到函数加入),MakeDelegate(this,
&CFrameWindowWnd::OnAlphaChanged);,当程序某个地方调用了CPaintManagerUI::SendNotify,并且Msg.pSender正好是this,我们的类成员回调函数将被调用。
搜寻CPaintManagerUI代码,我们发现还有一些消息过滤再里面:
bool CPaintManagerUI::AddMessageFilter(IMessageFilterUI* pFilter)
{
ASSERT(m_aMessageFilters.Find(pFilter)<0);
return m_aMessageFilters.Add(pFilter);
}
m_aMessageFilters也是IMessageFilterUI array,和m_aPreMessageFilters类似。
上面我们介绍的是CPaintManagerUI::AddPreMessageFilter,那这个又是在哪儿做的过滤?
还是CPaintManagerUI::MessageHandler中:
……
// Cycle through listeners
for( int i = 0; i < m_aMessageFilters.GetSize(); i++
)
{
bool bHandled = false;
LRESULT lResult = static_cast<IMessageFilterUI*>(m_aMessageFilters[i])->MessageHandler(uMsg, wParam, lParam, bHandled);
if( bHandled ) {
lRes = lResult;
return true;
}
}
… …
这个片段是在,异步OnNotify和Nofity消息响应,被调用后。才被调用的,优先级也就是最低。但它始终会被调用,因为异步OnNotify和Nofity消息响应没有返回值,不会因为消息已经被处理,而直接退出。DuiLib再次给用户一个处理消息的机会。用户可以选择将bHandled设置为True,从而终止消息继续传递。我觉得,这个通常是为了弥补OnNotify和Nofity没有返回值的问题,在m_aMessageFilters做集中处理。
处理完所有的消息响应后,如果消息没有被截断,CPaintManagerUI::MessageHandler继续处理大多数默认的消息,它会处理在其管理范围中的所有控件的大多数消息和事件等。
总结,DuiLib消息响应方式:
实现IMessageFilterUI接口,调用CPaintManagerUI:: AddPreMessageFilter,进行消息发送到窗口过程前的过滤。
重载HandleMessage函数,当消息发送到窗口过程中时,最先进行过滤。
实现INotifyUI,调用CPaintManagerUI::AddNotifier,将自身加入Notifier队列。
添加消息代理(其实就是将成员函数最为回到函数加入),MakeDelegate(this,
&CFrameWindowWnd::OnAlphaChanged);,当程序某个地方调用了CPaintManagerUI::SendNotify,并且Msg.pSender正好是this,我们的类成员回调函数将被调用。
话说DuiLib做界面,真是太方便了。我花了三天时间,从零开始学习,搞出了一个软键盘,发现逻辑上的代码量大大简化了。同样用MFC写,我的同事花了一周的时间,来调整布局和代码逻辑,里面写死了一堆要定位的坐标相关的值,如读天书一般,而且还很丑陋,再看看DuiLib做的软键盘,完全没有可比性。不过DuiLib的工具类如CDuiString等,会有一些bug。还是得继续完善。
相关文章推荐
- 《Java程序设计》第16周周四:GUI编程及文件对话框的使用
- ERROR ITMS-9000: "Redundant Binary Upload. There already exists a binary upload with build version '
- Creational模式之Builder模式
- VS2013编译duilibv1.1,“找不到Riched20.lib”的问题
- tableviewcell滑动显示多个按钮UITableViewRowAction(转载)
- LeetCode_63---Unique Paths II
- LeetCode_62---Unique Paths
- QueryPerformanceFrequency 和 QueryPerformanceCounter用法
- UICollectionView瀑布流制作
- Android UI 学习心得(一)
- JPA注解之“@GeneratedValue”详解
- .NET平台开源项目速览(6)FluentValidation验证组件介绍与入门(一)
- 【MAC使用技巧】QuickTime Player使用技巧
- android studio 新建项目 界面一直停在 【“building ‘ 项目名’ gradle project info”】
- 《Java程序设计》第16周周四:GUI编程及文件对话框的使用(项目二)
- GUI编程及文件对话框的使用
- Windows 10图标进化(从Build 9926开始):扁了 又不扁了
- Windows 10 Build 10151简体中文版多图预览
- requirejs使用
- iOS7之后UIBarButton在导航栏上的过大边距问题解决方案