DotNet剖析系列（二）
——控件继承
首先想要告诉大家的是MS一个龌龊的行为，一个人所共知的行为。而这个问题在所有MS提供的基本控件里都存在，比如我们想要对ComboBox这个控件稍微的扩展一下，加上一点点我们自已的东东。结果是很麻烦，很麻烦，甚至你都没办法使用继承来重载OnPaint。因为正常情况下，OnPaint在这个控件里永远不会调用，当然MS告诉你可以用this.SetStyle(ControlStyles.UserPaint)来激活这个方法，很好，不过当你运行了一下，发觉好象不是这么简单，
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint (e);
}
什么东东都没有了，就是一个白板，考，这时候你除了自已重新绘制，别无它法。
当然聪明的程序员不会被MS的小伎俩难倒。既然你不让我从OnPaint重载，你总得使用消息吧，那我重载WndProc
private static int WM_PAINT =0x000F;
protected override void WndProc(ref Message m)
{
base.WndProc (ref m);
if(m.Msg == WM_PAINT)
{
Graphics g =this.CreateGraphics();
//g.DrawLine(new Pen(Color.Blue), 0,0,100,100);
string str =this.GetStyle(ControlStyles.UserPaint).ToString();
g.DrawString(str,new Font("宋体",10),Brushes.Blue,new Rectangle(0,0,100,100));
g.Dispose();
}
}
很好，现在是不是你可以随心所欲地加上你自已想要的东东了。
方法知道了，想知道原理么？
程序员是追求真理的人群。老办法，还是请出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来组合几个基本控件。
