使用VB.NET开发自定义Windows控件

　　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 Basic 6.0 中，你只能不用控件或者直接引用现成的控件来实现各种功能性。例如：为了创建前面提到的自定义文本输入框，你就要新建一个 ActiveX 控件，然后向其中增加一个 TextBox 。

　　注意：人们通常把这种编程思路称为“容器” (containment) 或者“委托”(delegation)。在 Visual Basic 6.0 中，用于模拟继承机制的非控件类也可以采用这种思路。

　　此时，新建的 ActiveX 控件并不会如你所愿自动获得 TextBox 的某些属性 (比如 Text 属性)；这些属性只能由你编码实现。更糟的是，你必须用许多代码来确保 TextBox 始终占据整个窗体；你还得为新控件设计 resizing 事件处理程序。当然，经过一番折腾，你总会完成该控件的设计任务的，何况还有 ActiveX 控件界面向导能减轻你的负担。可是在 .NET 环境下，整个任务的完成思路都会变得完全不同。

　　继承性能避免控件开发中的某些重复代码，因为它能让 .NET 控件直接获得任何其它控件的功能性。例如：为了创建自己的 TextBox 控件，你可以继承现有的 TextBox 控件，而不是 UserControl 控件。新控件继承了基类控件的全部功能性，因此你只需要对基类控件中没有的功能性编码即可。下面举一个实际的