因为Control所具有的大部分控件机制他们不需要有。

例如Control的Add方法中重新实现了Page的Add中的全部功能——处理ViewState、事件等控制机制。Control还有Attribute、ControlStyle等等。

设计继承结构，不能因为一两个属性的继承就让子类继承一个过分的父类，否则这种设计就危害了系统的可理解性。

设计继承结构，不能因为一两个属性的继承就让子类继承一个过分的父类，否则这种设计就危害了系统的可理解性。

这句话说得比较好，:）

应用决定设计

设计继承结构，不能因为一两个属性的继承就让子类继承一个过分的父类，否则这种设计就危害了系统的可理解性。

这句话说得有道理！！！！

呵呵,俺能理解你的意思,俺说的是Win Form,

看看Component的成员吧只有10几个,这显然不够ToolBarButton和MenuItem用的,而且Button也是从Control继承而来的,ToolBarButton根据它的名字,说它是一类按钮(继承自Button)或许比说它是一类组件(继承自Component)要合理。

俺只说说俺觉得不爽的一个地方，俺要在一个ArrayList里放MenuItem和ToolBarButton和Button和其他继承自Control的东西，然后控制他们的Visible属性，自然要foreach(Component c in arraylist)了这样c就没有Visible属性，如果foreach(Control c in arrayList)，虽然有Visible，但是转型异常了。framework有没有一个接口啥的可以解决这个问题？

如果认为它们是一组按钮又如何？
微软的本意不是将toolbarbutton当作按钮用的

up

.net是基于组件的开发的,这话应怎样理解??

refer to:
http://msdn.microsoft.com/library/CHS/cpguide/html/cpconComponentProgrammingEssentials.asp?frame=true
http://msdn.microsoft.com/library/chs/default.asp?url=/library/CHS/cpguide/html/cpconclassvscomponentvscontrol.asp

ToolBarButton连个Click都没有，难怪要加在ToolBar里，而MenuItem有Click，我觉得.NET对Win Form的处理，MS偷了很多的懒，例如，ToolBarButton和MenuItem不能换颜色，我就想不通，换个颜色举手之劳而已，为啥不行；结构也不是很合理，例如Visible，Click，Text这样的属性虽然都有，但是就是用不了（用窗体设计器改当然很容易了，抛开不论）

不知道有没有人同意我？

因为大多数 .NET 的控件都是对 Windows 控件的包装，在包装过程中很多因为技术原因使得 .NET 的 WinForm 控件有些显得粗糙，要说清楚的话挺费篇章和时间，对此有疑惑的可以看看用 C 语言进行 Windows 编程的内容，这些内容 MSDN 里就有，看了以后就理解了。

可以举个例子，比如 ToolbarButton。其实 Windows 根本没有这个控件！这只是一个抽象概念！Toolbar 是对 Windows Toolbar 控件的包装，而 Windows Toolbar 是自己绘制那些 button 的，根本没有使用我们理解的那种 button，而其自己的 toolbar button 只有仅有的一点点功能，就是我们在 .NET 类库中看到的那些。因此，从技术上说，要全部实现 Control 或者 Button 里的所有事件、属性、方法等根本就是巨大的浪费，因为操作系统 Windows 不提供，而微软也不可能再次开发一个全新的 toolbar，所以最后决定从 Component 继承得了。

总的来说，还是因为 .NET 需要按时推出，不可能样样一下子就做得面面俱到，这在任何多版本的软件里都是这样的。

不过，好消息是——在今年即将推出的 .NET Framework 2.0 里将会大大增加现有的 Windows 控件，并且简化我们现有的开发难度。即时，大家还能使用像 Office 那样漂亮界面的控件！

不论什么环境，理念是一样的。设计师决定ToolBar必须是统一的外表，所以这个样式在ToolBar中定义的，不给你留下可以随意单独配置的印象。其他属性也是如此。事件同理也是通过ToolBar显露的。统一的考虑让这一堆有点臃肿的组件放在一起反而还是很容易掌握。当然作为高级程序员可以自己定义自己的ToolBarButton在控件绘制前加强显示效果，然后在事件中判断发送者的类型进行自定义的复杂处理。

MyNameEPC(MyName):

比较同意，不过2.0还是后话呢，早着呢。

这样说来MS还是偷懒了.可惜啊,好的控件都要 $ 啊,郁闷.

确上楼上朋友所说的，forms的控件太大，
我在查看.net控件源码时，一个comboBox就有3000行代码！！其它也一样大。
Control 这个基类，你们知道有多少行代码？？13000多行！！！

哈哈，还不如自己用C#写一个来得简单！！（我做类库时，如非必要从不在.net中继承！！）