VB6 UserControls: Differences between OCX vs. including in project

3
votes

In VB6, a UserControl can be compiled to an OCX and then included in another project as a referenced component. Alternately, the UserControl source itself (i.e., CTL file) can be included directly in an EXE or DLL project.

There is one curious difference between the two approaches. When used from an OCX, the list of Extender properties (more) is seamlessly merged with any custom properties defined for the control. But when used from a CTL this does not seem to be the case. Trying to use Extender properties on the control will generate compiler errors.

An example would be the .Tag property. When referencing as an OCX this property is available in Intellisense and compiles OK. But when using the CTL, the exact same use of this property generates a compile-time error.

Other examples would be .Left, .Top, etc. I expected VB6 to treat the Extender properties the same regardless of how the control was included.

Why does this difference exist, and is there any fix?

(Note: As a workaround, I have been referring to the controls in code as type Object when Extender properties need to be accessed. But ideally I would prefer to use the actual type for clarity and compile-time safety.)

2
vb6user-controlsocx
An OCX is a dll file with a funny name. You use COM to access it. VB6 has it's own internal COM for internal stuff that is a bit quicker. Perhaps that is the difference. – user6017774
@Noodles if so, it would seem to be an anomalous difference. Every other case I know of, bundling code into the EXE vs. compiling to a separate DLL/OCX makes no difference. – StayOnTarget
It's a difference in the framework that they are accessed by. It's only an hypothesis. But it is a difference between CTL and DLL – user6017774
I think you're running into a COM / interfaces issue. Try assigning your usercontrol to a variable of type UserControl and accessing the extender properties from there. – Adrian
Thank you for pointing out that declaring it as Object gives access to the Extender properties. – Jack Griffin

2 Answers

0
votes

If you have the source code for the control residing in your project, then when interacting with the control ( running its code ) you will see it, line by line when in step-debugging.

This can really slow you down if you are step debugging code that is not in the control. Hence, once your control is working and stable, it's time to compile it and use the OCX reference, until changes to the control are needed.

-1
votes

It has no real differences in the program at all. It is compiled into the program, so it is linked with the procedures of the control in difference, maybe you have some wrong code, which would not be noticed or is not illegal by the compiler with an external control. But it saves memory if you run some programs with the control, cause the code written for the control is only loaded once. And you could also change the control seperately, and you only need to compile it once (if you make the program for other people, they only need to update the changed excutable).