I use now CJ's Activex a few year and i'm very happy with this.
But ...
In the near past i get some new version, 11.1, 11.2.0, 11.2.1, 11.2.2, 12.0.0, 12.0.1, and have many problems with this.
Each version becomes from CJ unique filenames, e.g.
Codejock.ReportControl.v12.0.0.ocx
Codejock.ReportControl.v12.0.1.ocx
Codejock.ReportControl.Unicode.v12.0.0.ocx
Codejock.ReportControl.Unicode.v12.0.1.ocx
this seams to be nice, but this isn't !!
In ActiveX you have for each Object its own CLSID.
In the CLSID is a pathlink to the corresponding OCX-File.
The CLSID from the above files is always the same, so you can have only one ocx as current activex-versions.
This seams also to be nice, but this is not !!!
Have a look to the VB6-Projectfile.
Each reference have a description like this:
Object={7CAC59E5-B703-4CCF-B326-8B956D962F27}#12.0#0; Codejock.ReportControl.Unicode.v12.0.0.ocx
You see the CLSID, the version and the OCX-Name, and that's the point of interest:
At runtime, vb6 checks if the CLSID, Major- and Minor-Version and the OCX-Name is available.
If you now install a new version with the same CLSID your application will not be run until the application is recompiled.
You think, thats not a problem ?
Ofcourse, it is.
If i was alone in the universe, it doesn't matter, but i'm not alone.
So if a customer buy 2 different application, both uses CJ's ActiveX-Components, only the last one that is installed, works perfectly.
The first one get at starttime missing or wrong ocx-files.
If you let the customer install a demoversion of your software and later uninstall, the corresponding CLSID's will be deleted, so the other application has to reregister or somtimes to be reinstalled.
I develope also more than 1 application and my customers decide, which to buy or not.
Each uses CJ's Activex-Components.
And sometimes i have installation problems to my customers, becouse they want only one module to be updatet.
But this i can't do.
If i only update one module, the other modules works not any more.
So the customer need to update all of my modules and i don't have to forget, that all modules have to be recompiled.
For my applications, i can solve this problem, but ...
At the moment, CJ's Application-Developers has not so many shared customers, but may be in future ?
What to do so far ?
If you provide different OCX-Files, provide also different CLSID's !
For VB6-User give a simple helper program to actualize the projectfile with the new CLSID and OCX-Name (ang also back to previous versions).
If you provide same CLSID's you have also to provide same OCX-Files.
VB6 checks only, if the actual version installed is not less than the needed version !
Same OCX-Files have the additional features for Installer's.
In Windows exists the property SharedResourceDLL's.
If in the Installerfile (.msi, .msm) a dll is marked as Shared, than the installer will only count the dll's if they already installed.
If the new dll is newer (Version), than the current the dll will be replaced and also counted.
But if the files are always named different, this feature will not work.
Importend for that is also, that new features becomes new Names (mostly done with new Propertynames ore Methodes).
But the signature for methodes, properties and events have never to be changed.
It's better that you than provide new events or methods for the new features.
Let's discuss !
|