> I am trying to create an VB 6.0 ActiveX DLL in which I have a set of
> class modules defined with the following declaration:

> Public WithEvents ControlObject as XXXXX

> XXXXX is a VB 6.0 control type - either an intrinsic VB control
> (TextBox, etc.) or an ActiveX (.OCX) control (MaskEdBox, DTPicker,
> etc.)

> This declaration works with no problem for intrinsic VB controls.

> However, for classes that use this declaration for ActiveX controls,
> it works - but with the following quirks:

> 1) Any EXE that references these classes in the DLL must be compiled
> on the same PC as was the DLL (or we get a Run-time error '13' - Type
> mismatch - whenever the ControlObject property is assigned).

> 2) When XXXXX is a ListView control, recompiling the DLL without
> changing any code whatsoever causes the DLL to break binary
> compatibility (when the DLL project is set to binary compatible mode)
> after every recompile.

> These problems go away if I compile these classes into the EXE rather
> than into a DLL - but I would prefer to use a DLL if at all possible!

> Any information or suggestions would be much appreciated!!  Thanks.

> If you attempt to make certain types of changes (of which apparently this is
> one) to that library, binary compatability cannot be maintained.  You can
> still build your library, but applications that are to use this "new" code
> must be advised of the changes--that's what the registration bit is all
> about.

> There's a concise an informative discussion of this in the VB
> reference--it's definitely worth your time to read it.

> > Does anyone know anything about the problems described below?

> > I am trying to create an VB 6.0 ActiveX DLL in which I have a set of
> > class modules defined with the following declaration:

> > Public WithEvents ControlObject as XXXXX

> > XXXXX is a VB 6.0 control type - either an intrinsic VB control
> > (TextBox, etc.) or an ActiveX (.OCX) control (MaskEdBox, DTPicker,
> > etc.)

> > This declaration works with no problem for intrinsic VB controls.

> > However, for classes that use this declaration for ActiveX controls,
> > it works - but with the following quirks:

> > 1) Any EXE that references these classes in the DLL must be compiled
> > on the same PC as was the DLL (or we get a Run-time error '13' - Type
> > mismatch - whenever the ControlObject property is assigned).

> > 2) When XXXXX is a ListView control, recompiling the DLL without
> > changing any code whatsoever causes the DLL to break binary
> > compatibility (when the DLL project is set to binary compatible mode)
> > after every recompile.

> > These problems go away if I compile these classes into the EXE rather
> > than into a DLL - but I would prefer to use a DLL if at all possible!

> > Any information or suggestions would be much appreciated!!  Thanks.

> My problem is not understanding what binary compatibility is (I
> understand that already) but how to achieve it in light of the quirks
> that I'm experiencing.

> > My problem is not understanding what binary compatibility is (I
> > understand that already) but how to achieve it in light of the quirks
> > that I'm experiencing.

> If you've got a grip on Binary Compatibility, such that you know when this
> compatibility cannot be maintained, you should be in good shape.  In those
> instances, you'll have to re-register the library on any machine that uses
> it.  Registration is part of the make, so you won't have to manually do this
> on the machine you build the new version upon.  On other machines, though,
> you'll have to REGSVR32 it.

> I'm out of ideas then.  It's odd, though, what you describe is very
> characteristic of a registration problem.

> If your app uses ADO and you're using Win95/98, there's a subtle
> registration problem that can occur while installing DCOM and MDAC together.
> Apparently, if you do not restart after the DCOM installation, MDAC will
> silently fail to install properly.  You can always re-install MDAC, but the
> source of the error can be misleading.