MFC编程点滴系列2－MFC的消息机制

前段时间太忙了，今天终于可以闲一下，现在NBA火箭队第6场生死大战46：31领先。期待火箭可以打第7场。

今天来聊一聊MFC的消息机制。Windows是一个消息驱动(Message Driven)的系统（应该说所有的现代操作系统都是采用）消息驱动的。Windows API中的SendMessage和PostMessage相信大家都用过吧。消息对于一个系统来说是非常重要的。想想我们做桌面程序开发的大部分代码，都是从消息响应函数(Message Handler)开始的。

消息的作用就是告诉一个东西（在OOP中就是对象）去做一件事。但是对于一个运行着几十个进程和几百个线程的操作系统来说，消息的处理可就没那么简单了。怎样处理消息呢？不同的类库给出了不同的答案。MFC是Message Map，Qt的Signal & Slot，和一些开源软件的模版(template)实现的(Signal & Slot)都是很好的例子。Qt的Signal & Slot是它的精髓所在，也是它最有代表性的一个特点，不过它的实现需要moc。所以我认为目前最优雅和清爽的解决方案是最后一种。有兴趣的TX可以看看我之前的一片文章“VJGUI消息设计－兼谈MFC、QT和信号/槽机制”。下面我就开始介绍一下MFC的消息机制。

不知道TX们在看MFC的类图时有没有注意到CCmdTarget这个类。它可是很重要的一个基类哦。所有UI相关的类全部从它派生来的。那么这个类有什么特别呢？因为它实现了Message Map。相信MFC程序员都有在BEGIN_MESSAGE_MAP和END_MESSAGE_MAP之间添加消息相应函数声明的经历吧。为什么MFC要使用Message Map呢？直接用virtual function不就行了？想想MFC中各种控件的消息，如果全部使用virtual function，那么编译时会生成巨大的vtable，想想后果。另外，virtual function也不易相应用户输入。那么Message Map是怎样工作的呢？

假设MFC获取了一条消息，那么MFC将做以下的操作：

1. 通过handle找到目标窗口，然后在该类的Message Map中找与这条消息配对的响应函数声明，然后执行该函数；

2. 如果该类中没有找到，则寻找基类的Message Map；

3. 如果没有基类了，且MFC没有找到任何响应函数，则将消息传递给DefWindowProc；

 

正是由于这样的设计，所以MFC程序员的很多代码都是在控件或窗口的派生类中响应消息。如CDialog的OnInitDialog()，OnPaint()等等。另外，Message Pump也方便消息在不同线程之间传输。

 

下面再举一个例子：一个MDI程序的message传输路径是什么呢？

1. 活动的View；

2. 活动的Document；

3. Document template；

4. 活动的Child Frame；

5. App object；

6. Main frame；

那么对于同一个消息，我们可以在6个不同的地方写下同一个消息的响应函数，这也算是MFC比较灵活的地方之一了。想想看在199X年实现这样的构架也算是比较NB的一件事了。

 

今天先写道这里。