VB6 UserControls：OCX 与包含在项目中的差异答案

【问题标题】：VB6 UserControls: Differences between OCX vs. including in projectVB6 UserControls：OCX 与包含在项目中的差异
【发布时间】：2016-12-03 05:58:33
【问题描述】：

在 VB6 中，可以将 UserControl 编译为 OCX，然后作为引用组件包含在另一个项目中。或者，用户控件源本身（即 CTL 文件）可以直接包含在 EXE 或 DLL 项目中。

这两种方法之间有一个奇怪的区别。从 OCX 使用时，Extender properties (more) 列表与为控件定义的任何自定义属性无缝合并。但是当从 CTL 使用时，情况似乎并非如此。尝试在控件上使用 Extender 属性会产生编译器错误。

.Tag 属性就是一个例子。当引用为 OCX 时，此属性在 Intellisense 中可用并且编译正常。但是在使用 CTL 时，同样使用该属性会产生编译时错误。

其他示例是 .Left、.Top 等。我希望 VB6 以相同的方式处理 Extender 属性，无论控件是如何包含的。

为什么会存在这种差异，有什么解决办法吗？

（注意：作为一种解决方法，当需要访问 Extender 属性时，我一直将代码中的控件称为 Object 类型。但理想情况下，为了清晰和编译时安全，我更喜欢使用实际类型。 )

【问题讨论】：

OCX 是一个 dll 文件，名字很有趣。您使用 COM 来访问它。 VB6 有它自己的内部 COM 用于内部的东西，这有点快。也许这就是区别。
@Noodles 如果是这样，这似乎是一个异常的差异。我所知道的所有其他情况，将代码捆绑到 EXE 与编译到单独的 DLL/OCX 没有区别。
访问它们的框架不同。这只是一个假设。但这是 CTL 和 DLL 的区别
我认为您遇到了 COM / 接口问题。尝试将您的用户控件分配给 UserControl 类型的变量并从那里访问扩展器属性。
感谢您指出将其声明为 Object 可以访问 Extender 属性。

标签： vb6 user-controls ocx

【解决方案1】：

如果您的项目中有控件的源代码，那么在与控件交互（运行其代码）时，您将在分步调试中逐行看到它。

如果您正在逐步调试不在控件中的代码，这真的会减慢您的速度。因此，一旦您的控件工作且稳定，就可以编译它并使用 OCX 引用，直到需要对控件进行更改。

【讨论】：

【解决方案2】：

它在程序中根本没有真正的区别。它被编译到程序中，所以它与控件的程序有区别，也许你有一些错误的代码，这不会被编译器注意到或者是不非法的外部控件。但是如果你用控件运行一些程序会节省内存，因为为控件编写的代码只加载一次。并且你也可以单独更改控件，只需要编译一次（如果你为其他人制作程序，他们只需要更新更改的可执行文件）。

【讨论】：