This thread is for discussions of Keeping VB Components Compatible.

Looks like it is straight out of a text book.  I checked through it all and it is all correct.  I had to by a series of advanced COM/COM++/VB and COM books to decypher - ah I mean learn - the same information.  Even then this lays it out simply and more clearly.

If you are still dealing with VB 6 and want to write component oriented code then READ THIS ARTICLE - it will save you hours of stuffing around.

Here are a couple of tips:
1. Never overwrite the file have two directories and make sure that you go from one to the other each compile.  When you no longer need the old version go in and run "regsvr32 ComponentName.ocx /u" to keep the registry clean.
2. Make sure that you have every project referencing the OCX in the project group when you do anything but a binary compile.
3. Keep multiple versions in seperate version directories.  This helps support application versions that are currently out in the wild.  That way you can always match the GUID of a previous build.

Also, I have expeienced Controls that have had their GUID been  "accidently" changing .   This is done by compiling as project compatibility or no compatibility over your old .OCX (like in a Debug directory).  Normally this is not so much of a problem, but if you already have a project that references that .OCX it may fail to load forms, saying you should look at the FormName.Log.

The solution is actually pritty simple.
Create a new Project.  Put the new OCX on a blank form.  Save that form/project.  Go into the new and old project and form files with a text editor (notepad/wordpad) copy and paste the GUID (Big long number) out of the new project and into the old.  When putting the GUID into the old, you should be overwriting the GUID of the old version.  Here is what it looks like in the vbp:

*note the GUID is between the braces *
Object={9FE255D1-F32E-11D0-9E15-444553540000}#1.0#0; mlistx.ocx

and here is what it looks like in the form:

*note the GUID is between the braces *
Object = "{9FE255D1-F32E-11D0-9E15-444553540000}#1.0#0"; "mlistx.ocx"


Philip.

Very interesting article on component compatibility. It gave me good insight in something I had trouble with during a long time already.
I have the following question though:
how can you remove the traces of previous compiled versions from the system so that they do not show up as available resources? I used to compile with my Active-X component set to "No Compatibility" and now it's pretty hard to know which reference entry is the correct one since VB only shows part of the path to the file. I had to use Spy++ to see which reference is the correct one.  Well, I now learned how to correctly compile, so my reference list does not grow that quickly any more. But I would still like to get rid of these leftovers of old controls.

Any help would be appreciated !

Thanks,
dhnc

When I've had the same problem, I would follow these steps:

1.  Manually unregister the component with regsvr32 /u path.

2.  Edit the registry using your favorite tool

3.  Starting in HKEY_CLASSES_ROOT, search for the name of the component.  By the name, I mean the first portion of the PROGID.  For each class in the component, you will find two entries.  One is indexed by the name of the class (i.e. component.class).

4.  For every one that you find, delete the registry entry.  And make sure that you delete from the top level (i.e. either the CLSID or the PROGID).

5.  Reregister the component with regsvr32.

6.  Before starting, make sure that you backup the register.  This step is placed at the end to see if you're reading all the steps before starting.

That should clean everything up, from a component perspective.

Bruce Johnson
TAG Consulting
www.tagconsulting.com