Delphi 消息机制学习笔记
最近几天又将李维《Inside VCl》书中关于 Delphi 中 Windows 消息机制的实现看了一遍，这是第二遍了，本来看第一遍时已经完全看懂了，但没做笔记，害得我又看了一遍，这回下定决心写一个笔记。与此同时，我在网上游荡时幸运地看到了两篇论述 Delphi 消息框架的文章，某些部分分析得相当深入，非常好的 Delphi 消息机制总结。这下一来又不想写笔记了，但后来一琢磨他们这些文章写得虽然好，但毕竟不是自己写的，要想理清消息机制这条线，非要自己动笔写一下不可， 能将你认为懂的东西表述出来那才是真懂。在这里我不得不多说两句，李维的书中很多地方我认为写得并不是很好，有时某个主题虽然用了N长的篇幅去写，好像也没有上面的文章中某些部分写得透彻 ，例如 对 MakeObjectInstance 这个牛X函数表述我就认为写得一点都不好，所以不要老崇拜所谓的老大，呵呵。
在文中很多地方我会写得特别简单，因为更详细地描述在李维的书中以及我参考的文章里已经写得很清楚了，为此我不会再费笔墨，只是将整个流程串一下，并写几个有价值的范例。
正文
永远记住，无论你是用 SDK 还是借用 VCL 来创建窗口，都要遵循 Windows 的游戏规则，即先注册窗口类，然后再创建窗口实例，在消息循环中写实现代码。你还要知道 Windows 已经为了我们预注册了多个窗口类，例如“Edit”、“ComboBox”，这时候我们要做的就是直接创建这些窗口，无需注册窗口类了；在 Delphi 中这一切更简单了，VCL 全部为你做好了，你只需简单地在设计窗体上拖动你要的控件再写实现代码就可以了，是不是很 cool？
一，窗口的创建
VCL 中，具有句柄(Handle) 属性的真正窗口控件全部继承自 TWinControl，那就从 TWinControl 的创建开始说起。
VCL 中窗口的建立不是按照我们想象中的流程创建的，即先把所有的窗口都创建好，然后再调用，而是在需要时才创建。可能你还不能理解我这句话的意思，慢慢看。继承自 TWinControl 的窗口控件都会有 Handle 属性，当代码中需要 Handle 值时，通过该属性的 getter 调用 TWinControl.HandleNeeded 来获得句柄，这时如果窗体已经建立，直接返回句柄，否则先创建窗口实例，再返回句柄，因此窗口创建是在 TWinControl.HandleNeeded 中实现的。Borland 这样做的目的我想是最大程度地来节省系统资源吧。
TWinControl.HandleNeeded 中有几个重要的方法，通过他们才得以创建窗口。TWinControl.HandleNeeded 调用TWinControl.CreateHandle 来获得 Handle。但 CreateHandle 只是个包装函数，它首先调用 TWinControl.CreateWnd 来创建窗口，CreateWnd 是一个重要的过程，它先调用 TWinControl.CreateParams 设置创建窗口的参数，通过这些参数调用 RegisterClass API 注册窗口类，CreateWnd 然后调用 TWinControl.CreateWindowHandle，CreateWindowHandle 才是真正调用 CreateWindowEx API 创建窗口实例的函数。CreateHandle 、CreateWnd、CreateParams 、CreateWindowHandle 都是虚方法，派生类可以重载这些方法以获得更多的功能 ，其中 CreateParams 被重载的几率最大。
上面提到的方法源码我建议你都要仔细看一遍，加深印象，后面我提到的方法，你也都要看看源码，受益无穷呀，我将不再提示。
至此一个窗口算是建立起来了，但是还是无法正确运行，因为它还没有消息循环。
二，消息循环的实现
消息循环的实现是整个 VCL 消息框架中写得最精彩的地方，因为传统的 Windows 回调函数是一个静态函数，而 VCL 中的窗体是类，调用类方法时，除了函数本身的地址，还需一个 Self，在它们之间建立关联真不是一件容易的事情，需要大量的代码技巧，同时消息循环还要保证每秒钟能处理几百到几万次的消息量，因此代码更需要写得精巧。 研习这部分代码可能会花比较多的时间。
我们知道注册窗体类时就要提供窗体回调函数入口地址，那么可以想象到 VCL 中这个过程是发生在对 TWinControl.CreateWnd 的调用中，在该方法中，静态函数指针 @InitWndProc 被赋值给 WNDCLASSEX 结构中的 lpfnWndProc，这是 VCl 窗体首次建立消息循环的地方。
InitWndProc 第一次被调用时，通过 SetWindowLong API 将消息回调函数替换成 TWindowControl.FObjectInstance，而TWinControl.FObjectInstance 就是一个普通的 Pointer，赋值是在 TWinControl.Create 中通过那个最具 Magic 的函数 MakeObjectInstance 完成的，这个过程非常复杂，详细描述见参考[3]。
替换的结果是类方法 TWinControl.MainWndProc 成为真正的消息处理 Handler，随后的对应窗体实例的消息处理全部在 TWinControl.MainWndProc 中完成。其中还有一个细节就是消息在被 MainWndProc 处理之前还要调用一个纯汇编写的静态函数 -- StdWndProc 将消息统一派发[1]。至此完成消息回调从普通的静态函数到类方法的转变。
事实上 TWinControl.MainWndProc 是调用 WindowsProc 来实际处理窗口消息，在 TControl.Create 中 WindowsProc 是被指定成类中虚拟方法 WndProc。从 TControl 到实际的 VCL 窗体类这条继承链上，很多派生类都重载了 WndProc，从而每个重载该方法的派生类都会增加一些功能。当然在继承链的末端，例如 TForm，也可以重载 WndProc，来完成一些 tricky 代码。记住，如果你重载 WndProc，总是先处理自己想要的消息，然后将不处理的消息递交到父类的 WndProc 中处理。
在每一个继承类的 WndProc 中应该只处理维持窗体运作的最基本的消息，其他不处理的消息最终会在 TControl.WndProc 中被传递到 TObject.Diapatch。TObject.Diapatch 在自己和父类的动态方法表中查询相应消息 ID，如果找到了，则调用相应的方法。所有处理消息的类方法都应该以关键字 message 定义，这可以保证其入口地址都是存在动态方法表中，从而也保证需要处理的消息 可以在 TObject.Diapatch 执行过程中被调用。
如果在动态方表中还是无法查询到需要处理的消息，那么 TObject.Diapatch 会继续调用虚方法 DefaultHandler，TObject.DefaultHandler 只是个 PlaceHolder，该方法在 TWinControl 中被重载， TWinControl 继承类中鲜有继续重载该方法的类，可以认为消息最后一次被处理的机会就是发生在 TWinControl.DefaultHandler 中。我们知道在消息循环中不处理的消息最后都应该交给 Windows 的默认回调函数 DefWindowProc API 来处理， TWinControl.DefaultHandler 最主要的工作就是完成这个，除此之外，还完成几个额外的消息处理[2]。
VCL 的消息流程至此为止。
可能你还在为整个消息分派流程犯晕，让我用实例来分析一下吧。
三，VCL 完整的消息分派流程
1. TButton
新建一个 Application，在 Form1 上放一个 Button (缺省名为Button1)，在其 OnClick 事件中随便写点代码，加上断点，在调试之前，请打开 DCU 调试开关（Project->Options->Compiler->Use Debug DCUs）， 这个开关如果不打开，是没法调试 VCL 的，然后 F9 运行，当停留在断点上时，打开Call Stack 窗口（View->Debug Window->Call Stack）可看到调用顺序如下（从底往上看）：
| TForm1.Button1Click($9637C0) TControl.Click TButton.Click TButton.CNCommand((48401, 660, 0, 524948, 0)) TControl.WndProc((48401, 660, 524948, 0, 660, 0, 660, 8, 0, 0)) TWinControl.WndProc((48401, 660, 524948, 0, 660, 0, 660, 8, 0, 0)) TButtonControl.WndProc((48401, 660, 524948, 0, 660, 0, 660, 8, 0, 0)) TControl.Perform(48401,660,524948) DoControlMsg(524948,(no value)) TWinControl.WMCommand((273, 660, 0, 524948, 0)) TCustomForm.WMCommand((273, 660, 0, 524948, 0)) TControl.WndProc((273, 660, 524948, 0, 660, 0, 660, 8, 0, 0)) TWinControl.WndProc((273, 660, 524948, 0, 660, 0, 660, 8, 0, 0)) TCustomForm.WndProc((273, 660, 524948, 0, 660, 0, 660, 8, 0, 0)) TWinControl.MainWndProc((273, 660, 524948, 0, 660, 0, 660, 8, 0, 0)) StdWndProc(918056,273,660,524948) TWinControl.DefaultHandler((no value)) TControl.WMLButtonUp((514, 0, 48, 13, (48, 13), 0)) TControl.WndProc((514, 0, 852016, 0, 0, 0, 48, 13, 0, 0)) TWinControl.WndProc((514, 0, 852016, 0, 0, 0, 48, 13, 0, 0)) TButtonControl.WndProc((514, 0, 852016, 0, 0, 0, 48, 13, 0, 0)) TWinControl.MainWndProc((514, 0, 852016, 0, 0, 0, 48, 13, 0, 0)) StdWndProc(524948,514,0,852016) TApplication.HandleMessage TApplication.Run Project1 |
一个 Button 被点击，在 TButton 内部会发生两个消息：WM_LBUTTONDOWN/WM_LBUTTONUP， TButton 没有处理 WM_LBUTTONUP（问题：为什么只响应 WM_LBUTTONUP，这两个消息只应该发生在 Windows 原生控件内，除非 TButton subclass 了 "Button"，这部分代码我没看），只是交给 TWinControl.DefaultHandler，随后 TButton 又将生成的 WM_COMMAND 消息发送给它的 Parent，即 TForm，经过一系列消息传递， WM_COMMAND 在 TWinControl.WMCommand 中被处理，通过 DoControlMsg 将 WM_COMMAND 加工成 CN_COMMAND，再利用 TControl.Perform 将 CN_COMMAND 传回 TButton，又通过一系列的消息传递到 TButton 中的 Dispatch，通过查询动态方法表找到 Handler -- TButton.CNCommand，它又调用虚方法 TButton.Click，继而调用 TControl.Click，在这个方法中会调用 FOnClick，而 FOnClick 特性值的内容就是当程序员使用对象查看器撰写 TButton 的 OnClick 事件处理函数时 Delphi 便会自动指定给 TButton 的 OnClick 特性，例子中 OnClick 被指定为 TForm1.Button1Click，因此 TForm1.Button1Click 最终被调用。
2. TForm
新建一个 Application，为 Form1 的 OnMouseDown 事件随便写一点代码，在这个方法上设断点，F9 运行，看看 Call Stack
| TForm1.FormMouseDown(???,???,[ssLeft],346,212) TControl.MouseDown(mbLeft,[ssLeft],346,212) TControl.DoMouseDown((513, 1, 346, 212, (346, 212), 0),mbLeft,[]) TControl.WMLButtonDown((513, 1, 346, 212, (346, 212), 0)) TControl.WndProc((513, 1, 13893978, 0, 1, 0, 346, 212, 0, 0)) TWinControl.WndProc((513, 1, 13893978, 0, 1, 0, 346, 212, 0, 0)) TCustomForm.WndProc((513, 1, 13893978, 0, 1, 0, 346, 212, 0, 0)) TWinControl.MainWndProc((513, 1, 13893978, 0, 1, 0, 346, 212, 0, 0)) StdWndProc(2687598,513,1,13893978) TApplication.HandleMessage TApplication.Run Project1 |
鼠标在 Form 上点击，产生两个消息 WM_LBUTTONDOWN/WM_LBUTTONUP，但我们只截获 WM_LBUTTONDOWN。产生的 WM_LBUTTONDOWN 经过一系列的消息传递到达 TObject.Dispatch，通过查询动态方法表在 TForm 的父类 TControl 中找到了 Handler -- TControl.WMLButtonDown，在 TControl.WMLButtonDown 中又经过 TControl.DoMouseDown、TControl.MouseDown 一系列方法调用，最终调用到 FOnMouseDown，FOnMouseDown 被赋值为 TForm1.FormMouseDown，调用 FOnMouseDown 即调用 TForm1.FormMouseDown。
讲了一大堆消息实现过程，那么在实际中到底有哪些应用？
四，消息的实际应用
如果你是共享软件作者，经常会为你的软件被 Crack 掉所烦恼，你能做的就是要加强你的软件的 Anti-Crack 功能，今天就交你一招。
如果你用过 Delphi 的专用反汇编工具 DEDE，那么你肯定知道像 Button1Click 这种 Event Handler 的方法入口地址 极容易被定位，其原理是根据TForm 的 RTTI 信息获取的（通过分析 dfm 资源文件就可以获得地址），其实 VCL 窗体只有 published 过的类成员才会生成 RTTI 信息。知道这个关键点加上对 VCL 消息机制的深入了解你就可以防止这一切发生。
1. Anti-Crack
新建一个 Application，在 Form1 上放两个 Button，命名为 btnRegister、btnCancel，双击这两个按钮，分别生成TForm1.btnCancelClick、TForm1.btnRegisterClick 两个 Event Handler 骨架代码，然后在对象查看器中取消 btnRegister.OnClick 与 TForm1.btnRegisterClick 的关联， 随后将 TForm1.btnCancelClick 的声明放入 TForms1 声明的 private 区段。再按照下面的代码 内容加入其他部分：
unit Unit1; |
这个方法的本质就是截获 TForm1 的 WM_COMMAND 消息并自己处理，请自行分析代码，我就不多说了。编译完后你可以用 DEDE 反汇编一下，看看还能不能那么容易地找到 TForm1.btnRegisterClick 的入口地址。
结束语
VCL 消息机制你理解了吗？是不是感到特别复杂？一个消息往往要经过10几个方法才能传到 Event Handler，别看消息传递经过这么漫长的路途，但是 VCL 消息机制的效率还是非常高的，因为很多关键的代码都是用汇编直接写成的，每一个中途站花费的时间也非常少，因此需要处理的消息还是能很快地到达目的地。
我最开始学 Windows 编程是从 SDK 开始学起的，那时候会写了基本的 Windows 程序，一段时间内总认为会 SDK 比会用 Delphi 牛X，现在想起来真傻，比起直来直去的 SDK 编程，VCL 消息机制要复杂得多得多，看完 VCL 源码后最大感受就是觉得以前跟没学过编程似的，但不可否认的是，只有在你掌握了 OOP/ASM/SDK 这些基础知识后，你才有看懂 VCL 源码的资本，这些基础知识你都掌握了吗？
参考文献
1. 李维.《深入核心 -- VCL架构剖析》第四、五章，2004.1
2. savetime."Delphi 的消息机制浅探", Jan 2004
3. cheka."VCL窗口函数注册机制研究手记，兼与MFC比较", 2001