We have a DLL (call it MyDLL.DLL) that references MyOCX.OCX.  The DLL has a
public object (call it MyObject) with a function (call it MyFunction) that
has a parameter of type Object.  The function assigns the Object parameter
to a module level variable dimmed as MyOCX.MyUserControl.

When the reference to MyOCX.OCX is added to the project for MyDLL.DLL, VB
creates the file MyOCX.OCA and adds Interface and Typelib entries to the
Registery for this OCA.

We then have a standard project (MyProject.vbp) that references both
MyOCX.OCX and MyDLL.DLL.  This project uses the MyOCX.OCA already created.

A form in the standard module has an instance of MyOCX.MyUserControl and
MyDLL.MyObject.  The Form calls MyObject.MyFunction passing the user control
MyOCX.MyUserControl as the Object parameter.

Everything is compiled, works fine and is checked into SourceSafe, including
MyProject.EXE, MyDLL.DLL, MtOCX.OCX and MyOCX.OCA files.

Problems then arise when another developer extracts from SourceSafe and
works on the project.

The second developer extracts all files from SourceSafe and registers the
DLL and OCX.  The developer can run MyProject.EXE without any problems.
However, when the developer opens MyProject.vbp, VB creates a new version of
the  file MyOCX.OCA and adds Interface and Typelib entries to the Registery
for this OCA.  The GUIDs for this new OCA are different to those in the OCA
created by the first developer.  When the call to MyObject.MyFunction is
made, there is an automation error when the Object parameter (which is of
type MyOCX.MyUserControl) is assigned to the module level variable (which is
also of type MyOCX.MyUserControl), saying the objects are not the same type.

We seemed to have solved this problem by the following:  When the second
developer extracts the files from SourceSafe, the OCA file is not extracted.
After letting the OCA be created on the second developers PC, the OCA file
from SourceSafe is extracted and overwrites the OCA just created.  This
process was working for several weeks, but has now ceased to work.

It seems the GUID for the user control on the form when in the development
environment comes from the OCA file rather than the OCX, but the GUID for
the user control in the DLL comes from the OCX.  I am only guessing as I
cannot find any detailed information about OCA files and related registery
settings.

By the way, if an OCA is deleted and then RegClean run, RegClean will remove
the Typelib registery entry for the OCA, but the Interface registery keys
for the controls in the OCX are not removed by RegClean.

Any help ith this would be greatly appreciated.

David Hay

we are facing the same problem as you describe. For the time being we
created a workaround by declaring your 'Object parameter to a module level
variable dimmed as MyOCX.MyUserControl' as object! This solves the problem
but gives you late binding for the object. A second problem with this
workaround occurs when you want to use WithEvents on the control, this won't
work on object types.
We currently have some guy from MS walking around who wants to have a look
at the problem. If he comes up with a real good solution I'll let you know.

Percy
PS Whenever you see the light on this problem please let me share the
solution.