VB6用户控件：OCX与包含在项目中的控件之间的差异

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

这两种方法之间有一个奇怪的区别。从OCX使用时，（）列表将与为控件定义的任何自定义属性无缝合并。但当从CTL使用时，情况似乎并非如此。尝试在控件上使用扩展程序属性将生成编译器错误

例如，

.Tag

属性。当引用为OCX时，此属性在Intellisense中可用，并可正常编译。但是当使用CTL时，同样使用这个属性会产生编译时错误

其他示例包括

.Left

，

.Top

，等等。我希望VB6对扩展器属性的处理是相同的，无论控件是如何包含的

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

---

（注意：作为一种解决方法，当需要访问扩展程序属性时，我一直将代码中的控件称为type

Object

。但理想情况下，为了清晰和编译时安全，我更愿意使用实际的类型。）

它在程序中没有任何实际的差异。它被编译到程序中，因此它与控件的程序链接不同，可能您有一些错误的代码，这些代码不会被外部控件的编译器注意到或是不合法的。

---

但如果使用该控件运行某些程序，则会节省内存，因为为该控件编写的代码只加载一次。您也可以单独更改控件，只需编译一次（如果您为其他人编写了程序，他们只需更新更改后的excutable）。

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

---

如果您正在调试不在控件中的代码，那么这确实会降低您的速度。因此，一旦控件工作且稳定，就应该编译它并使用OCX引用，直到需要更改控件为止

OCX是一个名称有趣的dll文件。您可以使用COM访问它。VB6有它自己的内部COM，用于更快的内部内容。也许这就是区别。如果是这样，那似乎是一种反常的区别。据我所知，将代码捆绑到EXE与编译到单独的DLL/OCX之间没有任何区别，只是它们所访问的框架有所不同。这只是一个假设。但是CTL和DLLI之间有一个区别，我认为您遇到了COM/接口问题。请尝试将usercontrol分配给usercontrol类型的变量，并从中访问扩展程序属性。感谢您指出，将其声明为对象可以访问扩展程序属性。