Public WithEvents X as OCX - breaks Binary Compatibility 
Author Message
 Public WithEvents X as OCX - breaks Binary Compatibility

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.



Sat, 18 Sep 2004 22:56:52 GMT  
 Public WithEvents X as OCX - breaks Binary Compatibility
The 2 quirks you mention are really the same thing.  Binary compatibility is
a mechanism that allows you to update a library while maintaining a
pre-existing application's references to it.

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.


Quote:
> 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.



Sun, 19 Sep 2004 10:06:14 GMT  
 Public WithEvents X as OCX - breaks Binary Compatibility
Some one else on another newsgroup solved problem 2)  I'm still having
problem 1) -- so I will still be seeking suggestions for solving this.

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.

FYI, below is the solution to problem 2) (as posted on another
newsgroup by Eduardo Morcillo):

Don't make the variable Public. Make it Private and create a Property
Get/Set to access it:

Private WithEvents m_oControlObject as XXXXX

Public Property Get ControlObject As Object
    Set ControlObject = m_oControlObject
End Property

Public Property Set ControlObject(NewObj As Object)
    Set m_oControlObject = NewObj
End Property

================================================================================

Quote:

> The 2 quirks you mention are really the same thing.  Binary compatibility is
> a mechanism that allows you to update a library while maintaining a
> pre-existing application's references to it.

> 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.



Sun, 19 Sep 2004 21:44:35 GMT  
 Public WithEvents X as OCX - breaks Binary Compatibility


Quote:
> Some one else on another newsgroup solved problem 2)  I'm still having
> problem 1) -- so I will still be seeking suggestions for solving this.

> 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.


Mon, 20 Sep 2004 09:30:34 GMT  
 Public WithEvents X as OCX - breaks Binary Compatibility
I already know all of what you said - it doesn't have any bearing on
or help me solve this issue .....
Quote:



> > Some one else on another newsgroup solved problem 2)  I'm still having
> > problem 1) -- so I will still be seeking suggestions for solving this.

> > 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.



Mon, 20 Sep 2004 22:01:34 GMT  
 Public WithEvents X as OCX - breaks Binary Compatibility


Quote:
> I already know all of what you said - it doesn't have any bearing on
> or help me solve this issue .....

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.



Tue, 21 Sep 2004 01:53:06 GMT  
 Public WithEvents X as OCX - breaks Binary Compatibility
Thanks -- but I think you are out of ideas!  We are using Windows 2000
and all three machines we've tested on have DCOM and MDAC working.

Problem 1) is still an issue....

Quote:



> > I already know all of what you said - it doesn't have any bearing on
> > or help me solve this issue .....

> 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.



Tue, 21 Sep 2004 21:57:51 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Public WithEvents X as OCX - breaks Binary Compatibility

2. Public WithEvents X as OCX - breaks Binary Compatibility

3. Public WithEvents X as OCX - breaks Binary Compatibility

4. public VB.Label breaks binary compatibility?

5. BUG: Enumerated Type Parameters Break Binary Compatibility

6. Binary compatibility suddenly breaks after each build

7. Binary compatibility suddenly breaks after each build

8. VB6 & VB5 - Binary Compatibility Broken

9. Recompiling Breaks Binary Compatibility

10. ADO 2.1 > 2.5 Break binary compatibility

11. Use of Optional Parameters breaks binary compatibility?

12. Binary Compatibility Broken

 

 
Powered by phpBB® Forum Software