OCX Compatibility 
Author Message
 OCX Compatibility

Ok.. I need someone to explain something to me...

I have 3 apps.  Each one of these apps uses a custom ocx that I have made.
I send these apps out to clients and everyone is happy.

I make a change to the ocx (ostensibly to improve it).  If I just tell
everyone to copy the new ocx over the old one, all three apps fail to
function with the complaint that the ocx in question was not registered
properly.  Ok.. so using regsvr32 I walk them through the steps of
registering the ocx.  No dice...  same problem.

So, if I now re-compile the exe's with the new ocx and send out those exes,
things are fine.  Is there another solution?  Is there something I am
missing?

Is there a project setting?  Is there an ocx setting?  Is there a
solution???

Recompiling and sending out new exes and the new ocx is something I hope I
can get away from...

Any help appreciated...

--
Sincerely,

Jim Hobek

"He who would do good to another must do it in Minute Particulars.  General
Good is the plea of the scoundrel, hypocrite and flatterer."
William Blake



Sat, 15 Sep 2001 03:00:00 GMT  
 OCX Compatibility

Quote:
>I make a change to the ocx (ostensibly to improve it).  If I just tell
>everyone to copy the new ocx over the old one, all three apps fail to
>function with the complaint that the ocx in question was not registered
>properly....
>So, if I now re-compile the exe's with the new ocx and send out those exes,
>things are fine...

Jim,

Once you have the first stable version of your compiled OCX, copy it to a
new file called, (for example), myocx.cmp (for "compatibility").  Then, go
into the project properties in VB's IDE and go to the Component tab.  Set
the compatibility option to Binary Compatibility.   Below that option is a
filename text box with no prompt.  Click the "..." button next to it and
find your .CMP file.  That name should appear in that box now.  Click OK to
close that dialog.  You have just told VB to always make future versions
(future compiles) of this OCX compatible with the .CMP (your baseline)
version.

Now rebuild the OCX by recompiling.  Then rebuild your apps that use that
OCX.  YOu can now distribute both.  Any future OCX changes will remain
compatible to the original, and be "accepted" by the applications that use
it.

If you have to change or delete a public method or property in the future,
you will be warned that you will lose compatibility, although you can add
additional methods and properties (usually) without losing compatibility.
In any case, bug fixes and other minor tweaks to the OCX will not make it
incompatible now that you've told VB how to keep it compatible with the
baseline version.

Internally, VB assigns each OCX and DLL and "GUID" (Globally Unique
Identifier).  That number is stored in your applications that use that DLL
or OCX so it can find it in the registry at runtime and create the object
and interface with it properly.   However, VB, by default, changes that
number within the OCX or DLL each time you build it, unless you tell it to
remain "Binary Compatible" with a previous version.  As long as you can
retain binary compatibility (and VB will warn you when it no longer can),
you should be fine shipping just the updated OCXs to your customers in the
future.

Good Luck!

Vinnie Murdico
Software with Brains, Inc.
http://www.softwarewithbrains.com



Sat, 15 Sep 2001 03:00:00 GMT  
 OCX Compatibility
    Go into project properties, go to the Component tab, and select Binary
Compatibility and give it the file for your original OCX.  If you don't have
binary compatibility selected, you are assigning all new CLSIDs to your
control each time you compile.

--
Paul Parkhurst
Software Engineer

Quote:

>Ok.. I need someone to explain something to me...

>I have 3 apps.  Each one of these apps uses a custom ocx that I have made.
>I send these apps out to clients and everyone is happy.

>I make a change to the ocx (ostensibly to improve it).  If I just tell
>everyone to copy the new ocx over the old one, all three apps fail to
>function with the complaint that the ocx in question was not registered
>properly.  Ok.. so using regsvr32 I walk them through the steps of
>registering the ocx.  No dice...  same problem.

>So, if I now re-compile the exe's with the new ocx and send out those exes,
>things are fine.  Is there another solution?  Is there something I am
>missing?

>Is there a project setting?  Is there an ocx setting?  Is there a
>solution???

>Recompiling and sending out new exes and the new ocx is something I hope I
>can get away from...

>Any help appreciated...

>--
>Sincerely,

>Jim Hobek

>"He who would do good to another must do it in Minute Particulars.  General
>Good is the plea of the scoundrel, hypocrite and flatterer."
>William Blake



Sun, 16 Sep 2001 03:00:00 GMT  
 OCX Compatibility
Jim,

I am just going to expand on Paul's comments.

You VB EXE does not know your OCX by its name. It knows it only by its Class
ID, which is that long ugly number letter combination you see in the
registry. The Class ID of the components is embedded in you client app when
you compile it. You can only change it by recompiling, which is why that
works for you.

But the new OCX is an update. You would like to just be able to use it, and
you can if you give it the same Class ID. Binary compatibility requires that
you give it a file name, then attempts to give the new OCX (or DLL) the same
Class ID as the specified file. I copy my OCX/DLLs into a reference
directory, and point to this directory.

I say that it will "try" to give it the same Class ID, because it checks
whether you have changed the interface. In this context "changed" is
different from "expanded". You can add new things to the interface, but if
you remove any properties or methods, or change parameters or return types,
you should not give it the same Class ID. This is because your existing EXEs
will crash with the new interface. Respect the warning the compiler gives
you on this issue.

This is a very simple issue completely lacking in voodoo once you realize
that the computer does not know your OCX as "MyOCX". It know it only by the
alternate name, which is that long ugly classID. Unfortunately this is not
covered in easily accessible documentation.

I have sufficiently beat this horse, but if you want an analogy, when you go
down to trade off your cell phone for a better model or service plan, you
probably ask for the same number, because is written on your business cards.
Similar thing.
--
Kathleen



Mon, 17 Sep 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. MSCHRT20.ocx compatibility breakdown in latest version?

2. compatibility between ocx controls

3. Pb of compilation on VB6 with my ocx or pb of compatibility

4. Public WithEvents X as OCX - breaks Binary Compatibility

5. Binary compatibility in an OCX.

6. Public WithEvents X as OCX - breaks Binary Compatibility

7. prevent compatibility is broken when swithing from .exe project to .ocx project

8. Compatibility between ocx controls

9. Pb of compilation on VB6 with my ocx or pb of compatibility

10. MSComCtl.ocx browser compatibility

11. Compatibility between ocx controls

12. MSComCtl.ocx browser compatibility

 

 
Powered by phpBB® Forum Software