王凌峰 编译
前言
Microsoft® Visual Basic® 的组件支持历来都是它的一大卖点，于是第三方软件开发商们纷纷开发出各种具有新功能性的可视控件 (也有少数非可视控件) 供 Visual Basic 程序员选用。这种特殊的 Visual Basic 开发形式创造了无数的第三方控件——有的是共享软件/自由软件，有的则被放到柜台上销售。现在，人们甚至可以直接用 Visual Basic 开发自己的可视/非可视组件了。于是，组件的数量迅速增长，其中相当一部分都是
程序员 (或者开发小组) 为针对自己的开发任务设计的。
注意 你或你的开发小组过去购买的 Microsoft ActiveX 控件往往无须修改或重写就能直接移植到微软 .NET 环境下。具体而言，只要进入 Microsoft Visual Studio® .NET 的 IDE (集成开发环境) 环境，依次从菜单中选择：工具 Tool -> 自定义工具箱 Customize Toolbox) ，或者使用 .NET 框架实用程序 Aximp.exe (ActiveX 控件导入程序) ，就能让 .NET 应用
程序中调用现成的 ActiveX 控件了。可是，一旦某个控件在 .NET 环境下工作不正常，它的作者恐怕就应该考虑升级该控件了。所以，为了能在 .NET 环境中正常使用购来的第三方 ActiveX 控件，就应该到开发商的 Web 网站去看看它有没有出升级版或者 .NET 版。
在 .NET 编程世界里，人们对自定义 UI 组件的需求依然存在，只不过它们的创建过程有所不同。本文将探讨两个
问题：为什么要创建自己的 Microsoft Windows® 控件？在 Visual Basic .NET 中开发控件时有哪些方面不同于以往的 5.0 / 6.0 版？
为什么要开发你自己的控件？
为了限制 Windows 窗体TextBox 控件的文本类型，可以在窗体代码中添加该控件的KeyPress 事件处理
程序，以拦截用户的每次击键并检查该键对应的字符能否进入 TextBox ：
Private Sub TextBox1_KeyPress(ByVal sender As Object, _
ByVal e As System.Windows.Forms.KeyPressEventArgs) _
Handles TextBox1.KeyPress
If Not Char.IsDigit(e.KeyChar) Then
e.Handled = True
Else
e.Handled = False
End If
End Sub
注意 单纯依靠捕捉击键事件是无法确保输入 TextBox 的文本全是数字的，因为用户有时不是直接向 TextBox 中敲入字符，而是通过剪贴板粘贴字符给 TextBox ;何况 TextBox 文本的初值就有可能包含非法的字符。某些其它事件比如 TextChanged 等，或许能够捕捉到更多非法输入，但我更喜欢用 Validating 或者 Leave 事件，它们是在用户离开输入控件之后才对 TextBox 进行字符合法性检查。这么做诚然放弃了对用户输入的即时反应，却允许用户首先通过剪贴板输入“轻度犯规”的文本字符串 ，比如在禁止空格的输入框中粘贴 “3425 2343 2342 2342”，然后手工纠正输入框里的“犯规”字符。
向控件中手工添加事件处理程序代码并不太难，可是当你面临更复杂的编程任务，比如检验邮寄地址或者汽车的 VIN # (车辆识别号码) 的字符合法性时，你还会感到如此轻松吗？此时你会希望把同一段事件处理程序用于多个窗体甚至多个项目，或者将它提供给开发小组的其他成员共享。然而，提取窗体中的代码片段，连同安装指南和控件的命名规则一起发布，却是一个恶梦的开端。好在天无绝人之路，你只要把它连同一个自定义控件发布，就不会遭遇这种恶梦了，因为此时用户界面和相关代码都位于独立的组件中，而组件的发布相对要容易得多。通过组件发布的代码片段在升级上也方便些：你只需发布新版的组件即可，再也不必通过种种渠道公布新的代码片段让
程序员手工覆盖原先的代码了！
继承性如何改变了控件的开发？
在 .NET 中的控件开发已经和 Visual Basic 6.0 大相径庭。其根本原因，就是 .NET 引入了继承性。在 Visual
