MFC消息循环和消息泵

      首先，应该清楚MFC的消息循环(::GetMessage,::PeekMessage)，消息泵(CWinThread::PumpMessage)和MFC的消息在窗口之间的路由是两件不同的事情。在MFC的应用程序中(应用程序类基于CWinThread继承)，必须要有一个消息循环，他的作用是从应用程序的消息队列中读取消息，并把它派送出去(::DispatchMessage)。而消息路由是指消息派送出去之后，系统(USER32.DLL)把消息投递到哪个窗口，以及以后消息在窗口之间的传递是怎样的。

消息分为队列消息(进入线程的消息队列)和非队列消息(不进入线程的消息队列)。对于队列消息，最常见的是鼠标和键盘触发的消息，例如WM_MOUSERMOVE,WM_CHAR等消息；还有例如：WM_PAINT、WM_TIMER和WM_QUIT。当鼠标、键盘事件被触发后，相应的鼠标或键盘驱动程序就会把这些事件转换成相应的消息，然后输送到系统消息队列，由Windows系统负责把消息加入到相应线程的消息队列中，于是就有了消息循环(从消息队列中读取并派送消息)。还有一种是非队列消息，他绕过系统队列和消息队列，直接将消息发送到窗口过程。例如,当用户激活一个窗口系统发送WM_ACTIVATE, WM_SETFOCUS, and WM_SETCURSOR。创建窗口时发送WM_CREATE消息。在后面你将看到，MS这么设计是很有道理的，以及他的整套实现机制。

这里讲述MFC的消息循环，消息泵。先看看程序启动时，怎么进入消息循环的：
_tWinMain ->AfxWinMain ->AfxWinInit ->CWinThread::InitApplication ->CWinThread::InitInstance ->CWinThread::Run

非对话框程序的消息循环的事情都从这CWinThread的一Run开始...

第一部分：非对话框程序的消息循环机制

// thrdcore.cpp 
//  main running routine until thread exits 
int  CWinThread::Run() 
{ 
ASSERT_VALID( this ); 

//  for tracking the idle time state 
BOOL bIdle  =  TRUE; 
LONG lIdleCount  =   0 ; 

//  acquire and dispatch messages until a WM_QUIT message is received. 
for  (;;) 
{ 
//  phase1: check to see if we can do idle work 
while  (bIdle  &&   ! ::PeekMessage( & m_msgCur, NULL, NULL, NULL, PM_NOREMOVE)) 
{ 
//  call OnIdle while in bIdle state 
if  ( ! OnIdle(lIdleCount ++ )) 
bIdle  =  FALSE;  //  assume "no idle" state 
} 

//  phase2: pump messages while available 
do  
{ 
//  pump message, but quit on WM_QUIT 
if  ( ! PumpMessage()) 
return  ExitInstance(); 

//  reset "no idle" state after pumping "normal" message 
if  (IsIdleMessage( & m_msgCur)) 
{ 
bIdle  =  TRUE; 
lIdleCount  =   0 ; 
} 

}  while  (::PeekMessage( & m_msgCur, NULL, NULL, NULL, PM_NOREMOVE)); 
}  // 无限循环，退出条件是收到WM_QUIT消息。 

ASSERT(FALSE);  //  not reachable 
} 

这是一个无限循环，他的退出条件是收到WM_QUIT消息：
if (!PumpMessage())
return ExitInstance();

在PumpMessage中，如果收到WM_QUIT消息，那么返回FALSE,所以ExitInstance()函数执行，跳出循环，返回程序的退出代码。所以，一个程序要退出，只用在代码中调用函数

VOID PostQuitMessage( int nExitCode )。指定退出代码nExitCode就可以退出程序。

下面讨论一下这个函数Run的流程，分两步：

1,第一个内循环phase1。bIdle代表程序是否空闲。他的意思就是，如果程序是空闲并且消息队列中没有要处理的消息，那么调用虚函数OnIdle进行空闲处理。在这个处理中将更新UI界面(比如工具栏按钮的enable和disable状态)，删除临时对象(比如用FromHandle得到的对象指针。由于这个原因，在函数之间传递由FromHandle得到的对象指针是不安全的，因为他没有持久性)。OnIdle是可以重载的，你可以重载他并返回TRUE使消息循环继续处于空闲状态。

NOTE：MS用临时对象是出于效率上的考虑，使内存有效利用，并能够在空闲时自动撤销资源。关于由句柄转换成对象，可以有若干种方法。一般是先申明一个对象obj,然后使用obj.Attatch来和一个句柄绑定。这样产生的对象是永久的，你必须用obj.Detach来释放对象。

2，第二个内循环phase2。在这个循环内先启动消息泵(PumpMessage),如果不是WM_QUIT消息，消息泵将消息发送出去(::DispatchMessage)。消息的目的地是消息结构中的hwnd字段所对应的窗口。

 

// thrdcore.cpp 
BOOL CWinThread::PumpMessage() 
{ 
ASSERT_VALID( this ); 

// 如果是WM_QUIT就退出函数(return FALSE)，这将导致程序结束. 
if  ( ! ::GetMessage( & m_msgCur, NULL, NULL, NULL)) { 
#ifdef _DEBUG 
if  (afxTraceFlags  &  traceAppMsg) 
TRACE0( " CWinThread::PumpMessage - Received WM_QUIT.n " ); 
m_nDisablePumpCount ++ ;  //  application must die 
//  Note: prevents calling message loop things in 'ExitInstance' 
//  will never be decremented 
#endif  
return  FALSE; 
} 

#ifdef _DEBUG 
if  (m_nDisablePumpCount  !=   0 ) 
{ 
TRACE0( " Error: CWinThread::PumpMessage called when not permitted.n " ); 
ASSERT(FALSE); 
} 
#endif  

#ifdef _DEBUG 
if  (afxTraceFlags  &  traceAppMsg) 
_AfxTraceMsg(_T( " PumpMessage " ),  & m_msgCur); 
#endif  

//  process this message 

if  (m_msgCur.message  !=  WM_KICKIDLE  &&   ! PreTranslateMessage( & m_msgCur)) 
{ 
::TranslateMessage( & m_msgCur);  // 键转换 
::DispatchMessage( & m_msgCur);  // 派送消息 
} 
return  TRUE; 
} 

在这一步有一个特别重要的函数大家一定认识：PreTranslateMessage。这个函数在::DispatchMessage发送消息到窗口之前，进行对消息的预处理。PreTranslateMessage函数是CWinThread的成员函数，大家重载的时候都是在View类或者主窗口类中，那么，它是怎么进入别的类的呢？代码如下：
//thrdcore.cpp
BOOL CWinThread::PreTranslateMessage(MSG* pMsg)
{
ASSERT_VALID(this);

// 如果是线程消息，那么将会调用线程消息的处理函数
if (pMsg->hwnd == NULL && DispatchThreadMessageEx(pMsg))
return TRUE;

// walk from target to main window
CWnd* pMainWnd = AfxGetMainWnd();
if (CWnd::WalkPreTranslateTree(pMainWnd->GetSafeHwnd(), pMsg))
return TRUE;

// in case of modeless dialogs, last chance route through main
// window's accelerator table
if (pMainWnd != NULL)
{
CWnd* pWnd = CWnd::FromHandle(pMsg->hwnd);
if (pWnd->GetTopLevelParent() != pMainWnd)
return pMainWnd->PreTranslateMessage(pMsg);
}

return FALSE; // no special processing
}

由上面这个函数可以看出：

第一，如果(pMsg->hwnd == NULL),说明这是一个线程消息。调用CWinThread::DispatchThreadMessageEx到消息映射表找到消息入口，然后调用消息处理函数。

NOTE: 一般用PostThreadMessage函数发送线程之间的消息，他和窗口消息不同，需要指定线程id,消息激被系统放入到目标线程的消息队列中；用ON_THREAD_MESSAGE( message, memberFxn )宏可以映射线程消息和他的处理函数。这个宏必须在应用程序类(从CWinThread继承)中，因为只有应用程序类才处理线程消息。如果你在别的类(比如视图类)中用这个宏，线程消息的消息处理函数将得不到线程消息。
第二，消息的目标窗口的PreTranslateMessage函数首先得到消息处理权，如果函数返回FALSE，那么他的父窗口将得到消息的处理权，直到主窗口；如果函数返回TRUE(表示消息已经被处理了)，那么就不需要调用父类的PreTranslateMessage函数。这样，保证了消息的目标窗口以及他的父窗口都可以有机会调用PreTranslateMessage--在消息发送到窗口之前进行预处理(如果自己处理完然后返回FALSE的话 -_-b),如果你想要消息不传递给父类进行处理的话，返回TRUE就行了。

第三，如果消息的目标窗口和主窗口没有父子关系，那么再调用主窗口的PreTranslateMessage函数。为什么这样？由第二步知道，一个窗口的父窗口不是主窗口的话，尽管它的PreTranslateMessage返回FALSE，主窗口也没有机会调用PreTranslateMessage函数。我们知道，加速键的转换一般在框架窗口的PreTranslateMessage函数中。我找遍了MFC中关于加速键转换的处理，只有CFrameWnd,CMDIFrameWnd，CMDIChildWnd等窗口类有。所以，第三步的意思是，如果消息的目标窗口(他的父窗口不是主窗口，比如一个这样的非模式对话框)使消息的预处理继续漫游的话(他的PreTranslateMessage返回FALSE)，那么给一次机会给主窗口调用PreTranslateMessage(万一他是某个加速键消息呢？)，这样能够保证在有非模式对话框的情况下还能保证主窗口的加速键好使。

我做了一个小例子，在对话框类的PreTranslateMessage中，返回FALSE。在主窗口显示这个非模式对话框，在对话框拥有焦点的时候，仍然能够激活主窗口的快捷键。

总之，整个框架就是让每个消息的目标窗口(包括他的父窗口)都有机会参与消息到来之前的处理。呵呵~

至此，非对话框的消息循环和消息泵的机制就差不多了。这个机制在一个无限循环中，不断地从消息队列中获取消息，并且保证了程序的线程消息能够得到机会处理，窗口消息在预处理之后被发送到相应的窗口处理过程。那么，还有一点疑问，为什么要一会儿调用::PeekMessage,一会儿调用::GetMessage呢，他们有什么区别？

NOTE：一般来说，GetMessage被设计用来高效地从消息队列获取消息。如果队列中没有消息，那么函数GetMessage将导致线程休眠(让出CPU时间)。而PeekMessage是判断消息队列中如果没有消息，它马上返回0，不会导致线程处于睡眠状态。

在上面的phase1第一个内循环中用到了PeekMessage，它的参数PM_NOREMOVE表示并不从消息队列中移走消息，而是一个检测查询，如果消息队列中没有消息他立刻返回0，如果这时线程空闲的话将会引起消息循环调用OnIdle处理过程(上面讲到了这个函数的重要性)。如果将::PeekMessage改成::GetMessage(***),那么如果消息队列中没有消息，线程将休眠，直到线程下一次获得CPU时间并且有消息出现才可能继续执行，这样，消息循环的空闲时间没有得到应用，OnIdle也将得不到执行。这就是为什么既要用::PeekMessage(查询),又要用::GetMessage(做实际的工作)的缘故。
第二部分: 对话框程序的消息循环机制

基于对话框的MFC工程和上面的消息循环机制不一样。实际上MFC的对话框工程程序就是模式对话框。他和上面讲到的非对话框程序的不同之处，主要在于应用程序对象的InitInstance()不一样。

 

// dlg_5Dlg.cpp 
BOOL CDlg_5App::InitInstance() 
{ 
AfxEnableControlContainer(); 
#ifdef _AFXDLL 
Enable3dControls();  //  Call this when using MFC in a shared DLL 
#else  
Enable3dControlsStatic();  //  Call this when linking to MFC statically 
#endif  

CDlg_5Dlg dlg;  // 定义一个对话框对象 
m_pMainWnd  =   & dlg; 
int  nResponse  =  dlg.DoModal();  // 对话框的消息循环在这里面开始 
if  (nResponse  ==  IDOK) 
{ 
//  TODO: Place code here to handle when the dialog is 
//  dismissed with OK 
} 
else   if  (nResponse  ==  IDCANCEL) 
{ 
//  TODO: Place code here to handle when the dialog is 
//  dismissed with Cancel 
} 

//  Since the dialog has been closed, return FALSE so that we exit the 
//  application, rather than start the application's message pump. 
return  FALSE; 
} 

NOTE: InitInstance函数返回FALSE，由最上面程序启动流程可以看出，CWinThread::Run是不会得到执行的。也就是说，上面第一部分说的消息循环在对话框中是不能执行的。实际上，对话框也有消息循环，她的消息循环在CDialog::DoModal()虚函数中的一个RunModalLoop函数中。 

这个函数的实现体在CWnd类中： 
int  CWnd::RunModalLoop(DWORD dwFlags) 
{ 
ASSERT(::IsWindow(m_hWnd));  //  window must be created 
ASSERT( ! (m_nFlags  &  WF_MODALLOOP));  //  window must not already be in modal state 

//  for tracking the idle time state 
BOOL bIdle  =  TRUE; 
LONG lIdleCount  =   0 ; 
BOOL bShowIdle  =  (dwFlags  &  MLF_SHOWONIDLE)  &&   ! (GetStyle()  &  WS_VISIBLE); 
HWND hWndParent  =  ::GetParent(m_hWnd); 
m_nFlags  |=  (WF_MODALLOOP | WF_CONTINUEMODAL); 
MSG *  pMsg  =   & AfxGetThread() -> m_msgCur; 

//  acquire and dispatch messages until the modal state is done 
for  (;;) 
{ 
ASSERT(ContinueModal()); 

//  phase1: check to see if we can do idle work 
while  (bIdle  &&   ! ::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE)) 
{ 
ASSERT(ContinueModal()); 

//  show the dialog when the message queue goes idle 
if  (bShowIdle) 
{ 
ShowWindow(SW_SHOWNORMAL); 
UpdateWindow(); 
bShowIdle  =  FALSE; 
} 

//  call OnIdle while in bIdle state 
if  ( ! (dwFlags  &  MLF_NOIDLEMSG)  &&  hWndParent  !=  NULL  &&  lIdleCount  ==   0 ) 
{ 
//  send WM_ENTERIDLE to the parent 
::SendMessage(hWndParent, WM_ENTERIDLE, MSGF_DIALOGBOX, (LPARAM)m_hWnd); 
} 
if  ((dwFlags  &  MLF_NOKICKIDLE)  ||   ! SendMessage(WM_KICKIDLE, MSGF_DIALOGBOX, lIdleCount ++ )) 
{ 
//  stop idle processing next time 
bIdle  =  FALSE; 
} 
} 

//  phase2: pump messages while available 
do  
{ 
ASSERT(ContinueModal()); 

//  pump message, but quit on WM_QUIT 
// PumpMessage(消息泵)的实现和上面讲的差不多。都是派送消息到窗口。 
if  ( ! AfxGetThread() -> PumpMessage()) 
{ 
AfxPostQuitMessage( 0 ); 
return   - 1 ; 
} 

//  show the window when certain special messages rec'd 
if  (bShowIdle  &&  (pMsg -> message  ==   0x118   ||  pMsg -> message  ==  WM_SYSKEYDOWN)) 
{ 
ShowWindow(SW_SHOWNORMAL); 
UpdateWindow(); 
bShowIdle  =  FALSE; 
} 

if  ( ! ContinueModal()) 
goto  ExitModal; 

//  reset "no idle" state after pumping "normal" message 
if  (AfxGetThread() -> IsIdleMessage(pMsg)) 
{ 
bIdle  =  TRUE; 
lIdleCount  =   0 ; 
} 

}  while  (::PeekMessage(pMsg, NULL, NULL, NULL, PM_NOREMOVE)); 
}  // 无限循环 

ExitModal: 
m_nFlags  &=   ~ (WF_MODALLOOP | WF_CONTINUEMODAL); 
return  m_nModalResult; 
} 

先说说怎么退出这个无限循环，在代码中：
if (!ContinueModal())
goto ExitModal;

决定是否退出循环，消息循环函数返回也就是快要结束结束程序了。
BOOL CWnd::ContinueModal()
{
return m_nFlags & WF_CONTINUEMODAL;
}

NOTE: CWnd::ContinueModal()函数检查对话框是否继续模式。返回TRUE,表示现在是模式的；返回FALSE，表示对话框已经不是模式(将要结束)。

如果要结束对话框，在内部最终会调用函数CWnd::EndModalLoop，它取消m_nFlags的模式标志(消息循环中的ContinueModal函数将返回FALSE，消息循环将结束，程序将退出)；然后激发消息循环读取消息。也就是说，结束模式对话框是一个标志，改变这个标志就可以了。他的代码是：
//wincore.cpp
void CWnd::EndModalLoop(int nResult)
{
ASSERT(::IsWindow(m_hWnd));

// this result will be returned from CWnd::RunModalLoop
m_nModalResult = nResult;

// make sure a message goes through to exit the modal loop
if (m_nFlags & WF_CONTINUEMODAL)
{
m_nFlags &= ~WF_CONTINUEMODAL;
PostMessage(WM_NULL);
}
}

NOTE: PostMessage(NULL)是有用的。如果消息队列中没有消息的话，可能消息循环中的ContinueModal()不会马上执行，发送一个空消息是激发消息循环马上工作。

下面说一下CWnd::RunModalLoop函数中的消息循环究竟干了些什么事情:

1,第一个内循环。首先从消息队列中查询消息，如果对话框空闲，而且消息队列中没有消息，他做三件事情，大家应到都能从字面上明白什么意思。最重要的是发送WM_KICKIDLE消息。为什么呢？第一部分讲到了，非对话框程序用OnIdle来更新用户界面(UI)，比如工具栏，状态栏。那么，如果对话框中也有工具栏和状态栏呢，在哪里更新(网上有很多这样的程序)？可以处理WM_KICKIDLE消息：
LRESULT CDlg_5Dlg::OnKickIdle(WPARAM w,LPARAM l)
{
//调用CWnd::UpdateDialogControls更新用户界面
UpdateDialogControls(this, TRUE);
return 0;
}

NOTE: CWnd::UpdateDialog函数发送CN_UPDATE_COMMAND_UI消息给所有的用户界面对话框控件。

2,第二个内循环。最重要的还是PumpMessage派送消息到目标窗口。其他的，像第二个if语句，0x118消息好像是WM_SYSTIMER消息(系统用来通知光标跳动的一个消息)。也就是说，如果消息为WM_SYSTIMER或者WM_SYSKEYDOWN,并且空闲显示标志为真的话，就显示窗口并通知窗口立刻重绘。

总之，对话框的消息循环机制和非对话框(比如SDI,MDI)还是类似的，仅仅侧重点不同。模式对话框是模式显示，自然有他的特点。下面部分讨论一下模式对话框和非模式对话框的区别。因为模式对话框有自己的特殊消息循环；而非模式对话框，共用程序的消息循环，和普通的窗口已经没有什么大的区别了。
第三部分：模式对话框和非模式对话框的区别

这个话题已经有很多人讨论，我说说我所理解的意思。

在MFC框架中，一个对话框对象DoModal一下就能产生一个模式对话框，Create一下就能产生一个非模式对话框。实际上，无论是模式对话框还是非模式对话框，在MFC内部都是调用::CreateDialogIndirect(***)函数来创建非模式对话框。只是模式对话框作了更多的工作，包括使父窗口无效，然后进入自己的消息循环等等。::CreateDialogIndirect(***)函数最终调用CreateWindowEx函数通知系统创建窗体并返回句柄，他内部没有实现自己的消息循环。

非模式对话框创建之后立即返回，并且和主程序共用一个消息循环。非模式对话框要等对话框结束之后才返回，自己有消息循环。比如下面的代码：
CMyDlg* pdlg = new CMyDlg;
pdlg ->Create(IDD_DIALOG1);
pdlg->ShowWindow(SW_SHOW);
MessageBox("abc");

非模式对话框和消息框MessageBox几乎是同时弹出来。而如果将Create改成DoModal，那么，只能弹出模式对话框，在关闭了对话框之后(模式对话框自己的消息循环结束)，消息框才弹出来。

NOTE：可以在模式对话框中调用GetParent()->EnableWindow(true);这样，主窗口的菜单，工具栏又激活了，能用了。MFC使用非模式对话框来模拟模式对话框，而在win32 SDK程序中，模式对话框激发他的父窗口Enable操作是没有效果的。

关于消息循环总结：

1，我们站在一个什么高度看消息循环？消息循环其实没有什么深奥的道理。如果一个邮递员要不断在一个城市中送信，我们要求他做什么？要求他来回跑，但他一次只能在一个地方出现。如果我们的应用程序只有一个线程的话，我们要他不断地为窗口传递消息，我们怎么做？在一个循环中不断的检测消息，并将他发送到适当的窗口。窗口可以有很多个，但消息循环只有一个，而且每时每刻最多只有一个地方在执行代码。为什么？ 看第二点。

2，因为是单线程的(程序进程启动的时候，只有而且有一个线程，我们称他为主线程),所以就像邮递员一样，每次只能在某一个地方干活。什么意思呢？举个例子，用::DiapatchMessage派送消息，在窗口处理过程(WinProc,窗口函数)返回之前，他是阻塞的,不会立即返回，也就是消息循环此时不能再从消息队列中读取消息，直到::DispatchMessage返回。如果你在窗口函数中执行一个死循环操作，就算你用PostQuitMessage函数退出，程序也会down掉。
while(1)
{
PostQuitMessage(0); //程序照样down.
}

所以，当窗口函数处理没有返回的时候，消息循环是不会从消息队列中读取消息的。这也是为什么在模式对话框中要自己用无限循环来继续消息循环，因为这个无限循环阻塞了原来的消息循环，所以，在这个无限循环中要用GetMessage,PeekMessage,DispatchMessage来从消息队列中读取消息并派送消息了。要不然程序就不会响应了，这不是我们所希望的。

以说，消息循环放在程序的什么的地方都基本上是过的去的，比如放在DLL里面。但是，最好在任何时候，只有一个消息循环在工作(其他的都被阻塞了)。然后，我们要作好的一件事情，就是怎么从消息循环中退出！当然用WM_QUIT是可以拉~(PostThreadMessage也是个好主意)，这个消息循环退出后，可能程序退出，也可能会激活另外一个被阻塞的消息循环，程序继续运行。这要看你怎么想，怎么去做。最后一个消息循环结束的时候，也许就是程序快结束的时候，因为主线程的执行代码也快要完了(除非BT的再作个死循环)。

NOTE: 让windows系统知道创建一个线程的唯一方法是调用API CreatThread函数(__beginthreadex之类的都要在内部调用他创建新线程)。好像windows核心编程说，在win2000下，系统用CreateRemoteThread函数来创建线程，CreateThread在内部调用CreateRemoteThread。不过这不是争论的焦点，至少win98下CreateRemoteThread并不能正常工作，还是CreateThread主持大局。

3，在整个消息循环的机制中，还必须谈到窗口函数的可重入性。什么意思？就是窗口函数(他是个回调函数)的代码什么时候都可以被系统(调用者一般是user32模块)调用。比如在窗口过程中，向自己的窗口SendMessage(***);那么执行过程是怎样的？

我们知道，SendMessage是要等到消息发送并被目标窗口执行完之后才返回的。那么窗口在处理消息，然后又等待刚才发送到本窗口的消息被处理后之后(SendMessage返回)才继续往下执行，程序不就互相死锁了吗？

其实是不会的。windows设计一套适合SendMessage的算法，他判断如果发送的消息是属于本线程创建的窗口的，那么直接由user32模块调用窗口函数(可能就有窗口重入)，并将消息的处理结果结果返回。这样做体现了窗口重入。上面的例子，我们调用SendMessage(***)发送消息到本窗口，那么窗口过程再次被调用，处理完消息之后将结果返回，然后SendMessage之后的程序接着执行。对于非队列消息，如果没有窗口重入，不知道会是什么样子。

NOTE: 由于窗口的可重入性。在win32 SDK程序中应尽量少用全局变量和静态变量，因为在窗口函数执行过程中可能窗口重入，如果重入后将这些变量改了，但你的程序在窗口重入返回之后继续执行，可能就是使用已经改变的全局或静态变量。在MFC中(所有窗口的窗口函数基本上都是AfxWndProc)，按照类的思想进行了组织，一般变量都是类中的，好管理的多。

4,MFC中窗口类(比如C**View,CFrameWnd等)中的MessageBox函数，以及AfxMessageBox函数都是阻塞原有的消息循环的。由消息框内部的一个消息循环来从消息队列中读取消息，并派送消息(和模式对话框类似)。实际上，这些消息函数最终调用的是::MessageBox，它在消息框内部实现了一个消息循环(原有的主程序消息循环被阻塞了)。论坛中碰到过几次关于计时器和消息框的问题，看下面的代码：
void CTest_recalclayoutView::OnTimer(UINT nIDEvent)
{
// TODO: Add your message handler code here and/or call default
MessageBox("abc");
while(1); //设计一个死循环
CView::OnTimer(nIDEvent);
}

咱让OnTimer大约5秒钟弹出一个消息框。那么，消息框不断的被弹出来，只要消息框不被关闭，那么程序就不会进入死循环。实际上，每次弹出对话框，都是最上层的那个消息框掌握着消息循环，其他的消息循环被阻塞了。只要不关闭最上面的消息框，while(1);就得不到执行。如果点了关闭，程序就进入了死循环，只能用ctrl+alt+del来解决问题了。

5，消息循环在很多地方都有应用。比如应用在线程池中。一个线程的执行周期一般在线程函数返回之后结束，那么怎么延长线程的生命周期呢？一种方法就是按照消息循环的思想，在线程中加入消息循环，不断地从线程队列读取消息，并处理消息，线程的生命周期就保持着直到这个消息循环的退出。

NOTE：只要线程有界面元素或者调用GetMessage,或者有线程消息发送过来，系统就会为线程创建一个消息队列。

6,在单线程程序中，如果要执行一个长时间的复杂操作而且界面要有相应的话，可以考虑用自己的消息泵。比如，可以将一个阻塞等待操作放在一个循环中，并将超时值设置得比较小，然后每个等待的片段中用消息泵继续消息循环，使界面能够响应用户操作。等等之类，都可以应用消息泵(调用一个类似这样的函数)：
BOOL CChildView::PeekAndPump()
{
MSG msg;
while(::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
{
if(!AfxGetApp()->PumpMessage())
{
::PostQuitMessage(0);
return false;
}
}
return true;
}

其实，用多线程也能解决复杂运算时的界面问题，但是没有这么方便，而且一般要加入线程通信和同步，考虑的事情更多一点。

综上所述，MFC消息循环就那么回事，主要思想还是和SDK中差不多。这种思想主要的特点表现在迎合MFC整个框架上，为整个框架服务，为应用和功能服务。

 

 几个消息循环中的常用函数进行对比

　　1 PostMessage 与 SendMessage 函数对比

　　SendMessage把消息直接发送到窗口，并调用此窗口的相应消息处理函数，等消息处理函数结束后SendMessage才返回!SendMessage发送的消息不进入系统的消息队列;SendMessage函数有返回值

　　PostMessage将消息发送到与创建窗口的线程相关联的消息队列后立即返回;PostMessage函数没有返回值;

　　2 GetMessage 与 PeekMessage函数的对比

　　GetMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax)

　　PeekMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax,UINT wRemoveMsg)

　　根据参数可以看出以上2个函数的区别，参数wRemoveMsg的作用是指定消息获取的方式，如果设为PM_NOREMOVE,那么消息将不会从消息队列中被移出，如果设为PM_REMOVE，那么消息将会从消息队列中被移出;

　　还有区别：

　　他们如果没有捕获到消息，程序的主线程会被操作系统挂起。当操作系统再次回来照顾此线程时，发现消息队列中仍然没有消息可取，此时两个函数的行为就不同了：

　　GetMessage : 过门不入，操作系统再次挂起此线程，去照顾别的线程;

　　PeekMessage: 取回控制权，使程序执行一段时间，等待可能的消息进入消息队列并将其捕获;这时程序进入空闲时间阶段;

 

补：

一．SDK下的消息机制实现

一般来说，Windows的消息都是和线程相对应的。即Windows会把消息发送给和该消息相对应的线程。

Win32程序的主体

WinMain(…)
{
   MSG msg;
   RegisterClass(…);            //  注册窗口类
   CreateWindow(…);             //  创建窗口
   ShowWindow(…);               //  显示窗口
   UpdateWindow(…);
   While(GetMessage( & msg,…)){    //  消息循环
       TranslateMessage(…); // 把虚键消息翻译成字符消息并放到响应的消息队列里面
      DispatchMessage(…); // 消息分发到相关的窗口过程
}

 

在SDK的模式下，程序是通过GetMessage函数从和某个线程相对应的消息队列里面把消息取出来并放到一个特殊的结构里面，一个消息的结构是一个如下的structure。

 

typedef  struct  tagMSG {

HWND hwnd;   // 表示和窗口过程相关的窗口的句柄

UINT message; // 消息的ID号

WPARAM wParam; // 和消息相关的参数

LPARAM lParam; // 和消息相关的参数

DWORD time; // 消息发送的时间

POINT pt;  // 示消息发送时的鼠标的位置

}MSG;

 

在SDK编程过程中，用户需要在窗口过程中分析消息的类型和跟消息一起的参数的含义，做不同的处理，也就是通过一个巨大的switch/case结构进行不同的消息处理，相对比较麻烦，而MFC把消息调用的过程给封装起来，使用户能够通过ClassWizard方便地使用和处理Windows的各种消息，甚至在弄清楚MFC的消息机制后，用户完全可以添加自己的消息命令以及消息响应函数。

 

二．MFC的消息实现机制

我们可以看到，在MFC的框架结构下，可以进行消息处理的类的头文件里面都会含有DECLARE_MESSAGE_MAP()宏,这里主要进行消息映射和消息处理函数的声明。

#define  DECLARE_MESSAGE_MAP () \
private : \
static   const  AFX_MESSAGE_ENTRY _messageEntries[]; \
protected : \
static  AFX_DATA  const  AFX_MSGMAP messageMap; \
virtual   const  AFX_MSGMAP *  GetMessageMap()  const ; \

 

可以进行消息处理的类的实现文件里一般都含有如下的结构。

BEGIN_MESSAGE_MAP(CInheritClass, CBaseClass)

//{{AFX_MSG_MAP(CInheritClass)

//}}AFX_MSG_MAP

END_MESSAGE_MAP()

这里主要进行消息映射的实现和消息处理函数的实现。 

其中BEGIN_MESSAGE_MAP宏的定义如下：

 

#ifdef _AFXDLL

#define  BEGIN_MESSAGE_MAP(theClass, baseClass) \

const  AFX_MSGMAP *  PASCAL theClass::_GetBaseMessageMap() \

{  return   & baseClass::messageMap; } \

const  AFX_MSGMAP *  theClass::GetMessageMap()  const  \

{  return   & theClass::messageMap; } \

AFX_DATADEF  const  AFX_MSGMAP theClass::messageMap  =  \

{  & theClass::_GetBaseMessageMap,  & theClass::_messageEntries[ 0 ] }; \

const  AFX_MSGMAP_ENTRY theClass::_messageEntries[]  =  \

{ \

#else

#define  BEGIN_MESSAGE_MAP(theClass, baseClass) \

const  AFX_MSGMAP *  theClass::GetMessageMap()  const  \

{  return   & theClass::messageMap; } \

AFX_DATADEF  const  AFX_MSGMAP theClass::messageMap  =  \

{  & baseClass::messageMap,  & theClass::_messageEntries[ 0 ] }; \

const  AFX_MSGMAP_ENTRY theClass::_messageEntries[]  =  \

{ \

#endif

#define  END_MESSAGE_MAP() \

{ 0 ,  0 ,  0 ,  0 , AfxSig_end, (AFX_PMSG) 0  } \

}; \

可见，BEGIN_MESSAGE_MAP（）定义了两套宏，分别用于静态编译和动态编译。

 

相应的，END_MESSAGE_MAP()宏定义如下：

#define END_MESSAGE_MAP() \

            {0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } \

     }; \

在这里粘贴宏的具体定义只是为了让你更好的理解，并没有必要将它们熟记。不要被它们的样子吓坏，宏做的工作始终只是替换，你拿两个具体的类名称替换掉BEGIN_MESSAGE_MAP()宏中的两个参数，你就可以发现这个宏的具体功能和运行方式。

所有能够进行消息处理的类都是基于CCmdTarget类的，也就是说CCmdTarget类是所有可以进行消息处理类的父类。CCmdTarget类是MFC处理命令消息的基础和核心。

同时MFC定义了下面的两个主要结构:

AFX_MSGMAP_ENTRY

 

struct  AFX_MSGMAP_ENTRY

{

UINT nMessage;  //  windows message

UINT nCode;  //  control code or WM_NOTIFY code

UINT nID; 

//  control ID (or 0 for windows messages)

UINT nLastID; 

//  used for entries specifying a range of control id's

UINT nSig; 

//  signature type (action) or pointer to message #

AFX_PMSG pfn;  //  routine to call (or special value)

};

 

其中AFX_MSGMAP_ENTRY结构包含了一个消息的所有相关信息,其中

nMessage为Windows消息的ID号

nCode为控制消息的通知码

nID为Windows控制消息的ID

nLastID表示如果是一个指定范围的消息被映射的话，nLastID用来表示它的范围。

nSig表示消息的动作标识。

AFX_PMSG pfn 它实际上是一个指向和该消息相应的执行函数的指针。

 

和AFX_MSGMAP

 

struct  AFX_MSGMAP

{

#ifdef _AFXDLL

const  AFX_MSGMAP *  (PASCAL *  pfnGetBaseMap)();

#else

const  AFX_MSGMAP *  pBaseMap;

#endif

const  AFX_MSGMAP_ENTRY *  lpEntries;

}; 

      而AFX_MSGMAP主要作用是两个，一：用来得到基类的消息映射入口地址。二：得到本身的消息映射入口地址。

      实际上，MFC把所有的消息一条条填入到AFX_MSGMAP_ENTRY结构中去，形成一个数组，该数组存放了所有的消息和与它们相关的参数。同时通过AFX_MSGMAP能得到该数组的首地址，同时得到基类的消息映射入口地址，这是为了当本身对该消息不响应的时候，就调用其基类的消息响应。

 

现在我们来分析MFC是如何让窗口过程来处理消息的。用MFC向导生成的MFC AppWizard（exe）应用程序通常会自动生成五个类：CDocument，CView， CApp，CMainFrame和CAbout。这些类除了CApp都是继承自CWnd，也就是说他们都有各自的消息循环队列和消息处理函数，所以按照SDK编程经验，Windows应该把消息发送到特定的类，由那些特定的类的消息处理函数进行处理，但是实际上所有MFC的窗口类都通过钩子函数_AfxCbtFilterHook截获消息，并且在钩子函数_AfxCbtFilterHook中把窗口过程设定为AfxWndProc。原来的窗口过程保存在成员变量m_pfnSuper中。 这样做的原因，一是为了提高消息分发效率，而是为了能很好的兼容MFC2.4以及之前的版本。

所谓钩子函数hook，是Windows程序设计中的一种高级技术。通常消息都是停留在消息队列中等待被所隶属的窗口抓取，如果你设立了hook，就可以更早一步抓取消息，并且可以抓取不属于你的消息，送往你设定的一个所谓的“滤网函数（filter）”。

所以在MFC框架下，一般一个消息的处理过程是这样的。

(1) 函数AfxWndProc接收Windows操作系统发送的消息。

(2) 函数AfxWndProc调用函数AfxCallWndProc进行消息处理，这里一个进步是把对句柄的操作转换成对CWnd对象的操作。

(3) 函数AfxCallWndProc调用CWnd类的方法WindowProc进行消息处理。注意AfxWndProc和AfxCallWndProc都是AFX的API函数。而WindowProc已经是CWnd的一个方法。所以可以注意到在WindowProc中已经没有关于句柄或者是CWnd的参数了。

(4) 方法WindowProc调用方法OnWndMsg进行正式的消息处理，即把消息派送到相关的方法中去处理。

消息是如何派送的呢？实际上在CWnd类中都保存了一个AFX_MSGMAP的结构，而在AFX_MSGMAP结构中保存有所有我们用ClassWizard生成的消息的数组的入口，我们把传给OnWndMsg的message和数组中的所有的message进行比较，找到匹配的那一个消息。实际上系统是通过函数AfxFindMessageEntry来实现的。找到了那个message，实际上我们就得到一个AFX_MSGMAP_ENTRY结构，而我们在上面已经提到AFX_MSGMAP_ENTRY保存了和该消息相关的所有信息，其中主要的是消息的动作标识和跟消息相关的执行函数。然后我们就可以根据消息的动作标识调用相关的执行函数，而这个执行函数实际上就是通过ClassWizard在类实现中定义的一个方法。这样就把消息的处理转化到类中的一个方法的实现上。

举一个简单的例子，比如在View中对WM_LButtonDown消息的处理就转化成对如下一个方法的操作。

void CInheritView::OnLButtonDown(UINT nFlags, CPoint point)

{

// TODO: Add your message

handler code here and/or call default

CView::OnLButtonDown(nFlags, point);

}

注意这里CView::OnLButtonDown(nFlags, point)实际上就是调用CWnd的Default()方法。 而Default()方法所做的工作就是调用DefWindowProc对消息进行处理。这实际上是调用原来的窗口过程进行缺省的消息处理。

如果OnWndMsg方法没有对消息进行处理的话，就调用DefWindowProc对消息进行处理。这是实际上是调用原来的窗口过程进行缺省的消息处理。

所以如果正常的消息处理的话，MFC窗口类是完全脱离了原来的窗口过程，用自己的一套体系结构实现消息的映射和处理。即先调用MFC窗口类挂上去的窗口过程，再调用原先的窗口过程。并且用户面对和消息相关的参数不再是死板的wParam和lParam,而是和消息类型具体相关的参数。比如和消息WM_LbuttonDown相对应的方法OnLButtonDown的两个参数是nFlags和point。nFlags表示在按下鼠标左键的时候是否有其他虚键按下，point更简单，就是表示鼠标的位置。

同时MFC窗口类消息传递中还提供了两个函数，分别为WalkPreTranslateTree和PreTranslateMessage。我们知道利用MFC框架生成的程序，都是从CWinApp开始执行的，而CWinapp实际继承了CWinThread类。在CWinThread的运行过程中会调用窗口类中的WalkPreTranslateTree方法。而WalkPreTranslateTree方法实际上就是从当前窗口开始查找愿意进行消息翻译的类，直到找到窗口没有父类为止。在WalkPreTranslateTree方法中调用了PreTranslateMessage方法。实际上PreTranslateMessage最大的好处是我们在消息处理前可以在这个方法里面先做一些事情。举一个简单的例子，比如我们希望在一个CEdit对象里，把所有的输入的字母都以大写的形式出现。我们只需要在PreTranslateMessage方法中判断message是否为WM_CHAR,如果是的话，把wParam(表示键值)由小写字母的值该为大写字母的值就实现了这个功能。

继续上面的例子，根据我们对MFC消息机制的分析，我们很容易得到除了上面的方法，我们至少还可以在另外两个地方进行操作。

1、在消息的处理方法里面即OnChar中，当然最后我们不再调用CEdit::OnChar(nChar, nRepCnt, nFlags)，而是直接调用DefWindowProc(WM_CHAR,nChar,MAKELPARAM (nRepCnt,nFlags))。因为从我们上面的分析可以知道CEdit::OnChar(nChar, nRepCnt, nFlags)实际上也就是对DefWindowProc方法的调用。

2、我们可以直接重载DefWindowProc方法,对message类型等于WM_CHAR的，直接修改nChar的值即可。

 

三．添加自定义消息

首先弄清楚两点：

（1）谁要发送这个消息（2）谁要接受这个消息。　　

用一个简单的例子来说明。对象A向B（也可以就是A到A）发送消息。　　

1、 发送消息　　

首先在A的头文件中定义这个消息：

#define WM_USERMESSAGE WM_USER+30

所有自定义消息都是以WM_USER消息为基础加上一个任意的自然数来表示的。A是向外发送消息的对象，因此在A的某个方法（函数）里就会调用用来发消息的函数B::SendMessage()/B::PostMessage()，因为是B接受消息，因此是如上的形式。　　

2、 接受消息　　 　　

对象接受一个消息，应该有三部分：在头文件中有该消息的处理函数的原型；在实现文件中有接受消息映射的宏； 以及该消息的处理函数的具体实现。　　

2.1、 头文件中加上自定义消息的处理函数原型　　 　　

在DECLARE_MESSAGE_MAP（）语句之前，一对AFX_MSG之间加上如下形式的函数原型：　　

afx_msg LRESULT OnProcName( WPARAM wParam, LPARAM lParam )；　　 　　对Win32来说，wParam, lParam是传递消息最常用的手段。　　

2.2、 在实现文件中加上接受消息映射的宏　　 　　

在cpp文件里，BEGIN_MESSAGE_MAP语句之后，在一对AFX_MSG_MAP之间，增加 如下形式的代码：　 　　

ON_MESSAGE(WM_USERMESSAGE, OnProcName)　　

上面是不用分号结尾的。 　　

2.3、在实现文件中给出消息处理函数的具体实现。

 

SourcUrl