SOLVED: DLL-Sauna provided by Codejock

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 !

 

I have installed actually the version 12.0.0 and compiled with this version.

Than i install version 12.0.1 and the compiled exe will work automatically with version 12.0.1. You can check this with the processexplorer from sysinternals.

 

Ok, i think, now i deinstall version 12.0.0 and start the exe again.

Now VB6 shows a message, that ocx-files with version 12.0.0 are missing and end the execution regardless if the 12.0.1-files further exists.

I reinstalled version 12.0.0 and the program works now again with version 12.0.1 !

I start than the COM-Registrator for 12.0.0, but the program uses still version 12.0.1.

A strange thing is shown in the ProcessExplorer:

In the DLL-List are Codejock.Commandbars.Unicode.v12.0.0.ocx AND ALSO Codejock.Commandbars.Unicode.v12.0.1.ocx in use ???

Ok, now i deinstall version 12.0.1 and try to start the exe.

The exe never will be started without any message !?

Other exe do this, but one even not.

After i have recompiled this programm, it will start now with the version 12.0.0 and works fine.

 

This is, what i have tried to explain.

 

The other thing is the changing of some properties.

For example the ReportControl:

 

Version 11.2.2:

After i have added new records, each caption of the RecordItem's have an empty string.

Because i use CustomDraw, i checked at DrawItem-Event if the caption is empty, do somethings and fill now the caption to provide my own formatting. This is for performancereasons.

 

Now, in version 12.0.0 (also in 12.0.1) the Caption-Property is never an empty string, so my program shows nothing special, because it recognize, that all things done.

I must change the program to fill a space in the caption and check the space in DrawItem-Event.

If i clear the caption, ReportControl do a defaultformatting of the value so the caption is allready filled again.

 

This is, what i mean with "Changing behavears" of known properities or events.

In the past (i don't know the version) you have also changed the signature of an event, so the program must be changed and recompiled to work !

 

If now 2 different applications with different versions of CJ's, than maybe the results are not applicable.

1 application expected version 11.2.2 but works with 12.0.0.

 

In the Form-Source you will find then:

   Begin XtremeCommandBars.CommandBars xtCmdBars
      Left            =   3630
      Top             =   150
      _Version        =   786432
      _ExtentX        =   635
      _ExtentY        =   635
      _StockProps     =   0
      VisualTheme     =   2
      DesignerControls=   -1  'True
      DesignerControlsData=   "frmODBCMain.frx":08CA
   End

so the ProgId is "XtremeCommandBars.CommandBars".

This id will be found in the typelib and the typelib-id will be forwarded to the the last installed CJ-Version, because you say (and that i have checked), that all versions have the same typelib-id.

 

I found, this is DLL-Hell enough !

E.g. my Application will work with version 11.2.2 and get information that it's working with 12.0.0 ?

Should the program than end ?

Should he than deinstall the other application that he also buyed and is working with 12.0.0 or later versions in the future ?

 

I think, that can not be a solution.

 

We must have a solution, that different versions can run at the same time.

Vista-Users have this problem (mostly) not, because Vista install all ActiveX in his WinSXS-Subdirectory, so this may be working (no thought about other vista-problems).

 

I think, this can only by done, that the Typelib becomes also an unique id for each version, the classes himselve has already one.

 

The things, the programmer must do is, to change the TypeLib-Id in his project-file or you provide a tool, that can do this, if he want to use the new version.

 

This would also help to evaluate new versions without having conflicts for existing applications.

 

It seams, that the sequence of installation has some sideeffects.

I don't know, what is the reason, but windows is always heavy

 

After some more tests, i think i can reduce the problem to the Codejock.Controls-OCX.

 

If i install the 12.0.1, than some modules uses the 12.0.0-version, other uses both versions !

Normally, DLL's and also OCX will be loaded only once per process (cached in windows).

But in one exe, i found the Controls.OCX three times !

1 time in version 12.0.0

2 times in version 12.0.1

 

I don't know the dependicies.

 

The VB6-IDE uses always the new version, so i can't test both versions if both are installed.

 

I think, we can close this topic because the hell is only a little bit warm.

 

I work further with version 12.0.0, until some other errors (e.g. Combo-Dropdown in ReportControl) are solved.