VB6在.NET WinForm上创建ocx？

Question

我继承了一个VB6项目,它有一个带有VB控件的Form(Label等)和Windows Common控件(Treeview,ImageList等),它看起来像是一个用户控件的理想候选者.

我向同事提到了将其编译为在.NET WinForms项目中使用的ocx ActiveX控件的可能性.由于之前在C++项目中使用VB ocx的经验,他们有点惊骇:在原型设计阶段一切都很好但是当用于实际时有时间和刷新问题(对话框上的许多控件,控件之间的选项卡,停用然后激活对话框等).

有没有人有任何在.NET Windows窗体上使用VB6编写的ocx的经验？我可以期待微妙的问题,还是他们一起玩得很好？

Answer 1

为此，我很乐意使用Microsoft 的Interop Forms Toolkit 2.0从 .NET -> VB 6.0 开始。我已经做过很多次了。走另一条路可能会很痛苦。

你的同事所担心的是非常真实的。出现的问题是哪个控制在哪个时间集中，以及如何在幕后处理某些想法。一个典型的例子是跨控件进行 Tab 键切换。

假设您有一个带有一些 .NET 控件的 .NET 表单和一个 VB 6 Active X。此 ActiveX 中也将包含控件。现在，当您在 .NET 表单上进行 Tab 切换时，当您到达 ActiveX 时，您会期望在 ActiveX中的所有控件上进行 Tab 切换，但您没有！您将立即通过选项卡浏览整个 ActiveX 控件。这是个问题。

现在，如果您采用相反的方式，即 VB 6.0 中的 .NET，则必须在代码中满足此行为。这篇CodeProject 文章有一个名为 ActiveXHelpers 的优秀类，它可以做到这一点。但基本上它归结为手动处理 KeyPressed 事件，检查选项卡或 shift+tab，以及手动聚焦下一个/上一个控件。

现在，在您的情况下，您需要修改 VB 6 代码才能像这样运行。在 .NET 中重写控件很可能会更省力。我从未经历过令人耳目一新的问题，但就像我说的，我只使用过 .NET -> VB，而不是相反。无论哪种方式，都可能会带来很多麻烦，并且您很可能会遇到其他问题，例如下沉事件以及区分 VB 中的设计和运行时之间的差异。