DotNet剖析系列——控件继承

    首先想要告诉大家的是MS一个龌龊的行为，一个人所共知的行为。而这个问题在所有MS提供的基本控件里都存在，比如我们想要对ComboBox这个控件稍微的扩展一下，加上一点点我们自已的东东。结果是很麻烦，很麻烦，甚至你都没办法使用继承来重载OnPaint.因为正常情况下，OnPaint在这个控件里永远不会调用，当然MS告诉你可以用this.SetStyle（ControlStyles.UserPaint）来激活这个方法，很好，不过当你运行了一下，发觉好象不是这么简单，

    protected override void OnPaint(PaintEventArgs e)

       {

           base.OnPaint (e);

       }

    什么东东都没有了，就是一个白板，这时候你除了自已重新绘制，别无它法。

    当然聪明的程序员不会被MS的小伎俩难倒。既然你不让我从OnPaint重载，你总得使用消息吧，那我重载WndProc

    很好，现在是不是你可以随心所欲地加上你自已想要的东东了。

    方法知道了，想知道原理么？

    程序员是追求真理的人群。老办法，还是请出Reflector，分析分析源码，因为所有的控件都是从Control继承的，基本控件也不例外，那么我们来看看OnPaint方法是如何调用的？ Control类中的核心是WndProc，呵呵，这就是上篇也提到过的窗口过程，从这里跟踪起就象抓住了鱼网的拉纤。

    因为WM_PAINT常数值是15，很快我们就来了这一小段

  case 15:

          if (this.GetStyle(ControlStyles.UserPaint))

           {

                 this.WmPaint(ref m);

                 return;

           }

           this.DefWndProc(ref m);

           return;

    当WM_PAINT消息进入队列时，注意如果是UserPaint就会调用WmPaint，否则就由系统默认的过程处理。那么WmPaint里有些什么东东呢，太长了，不过总而言之，它会调用PaintWithErrorHandling这个方法，然后这个方法又会调用OnPaint，而OnPaint才会激发Paint事件。而Control和Form的UserPaint位都会默认设为true，因此才能够进行简单的重载OnPaint，而象基本控件其UserPaint都会是false，象上面重载WndProc而进行绘制的代码段，会打印出一个蓝色的false.

    那么MS是不是用Graphics的函数进行绘制这些基本控件的呢，原来我也以为会是，结果我在繁杂的代码里找了一大圈，答案是不是，实际上MS还是用的老办法，就象古老的C++程序一样，通过RegisterClass、CreateWindow来绘制标准的控件，并且将UserPaint设成了false，为什么要么做呢，难道不能使用Graphics来绘制么，这样不是一个更干净的。Net平台么，如果是考虑效率的问题，我想这不是个理由，事实上很多三方控件，都是直接使用Graphics来绘制控件，效率不是一样的出色么？

    原因只有一个，对于Windows这个MS最重要的产品，外观对于它而言是一个重要的技术专利，因此。net平台里就会看到很多这个原因引起的东东，比如说ControlPaint这个类，它的方法连基本的控件都不能全部绘制出来，还有XP都出来这么久了，XP样式的控件绘制。NET平台也不提供，它自家的控件倒是很方便地可以显示，三方控件能做到与它完全一致的少之又少。还用从源码中倒处可以看到sealed这个关键词，无它，还是让你没办法去重载它。

    本来。Net平台的设计是相当的完美，但是MS的商业意识让Windows下的。Net平台不会是一个最完美的。Net平台。

    下一篇是如何象MS一样做到在XP平台来显示控件XP样式。注意，这是你自已完全绘制的控件，不是简单的用UserControl来组合几个基本控件。