We had hot discussion about GUIDs and if possible to work with 2 versions on same PC.

Seems we need clarify things here:

How things look now:

1. All versions have same TYPELIB (identifier of whole ActiveX)

for example typelib for CommandBars ActiveX 14.0 is

same as CommandBars ActiveX  10.0:

Object={555E8FCC-830E-45CC-AF00-A012D5AE7451}#10.0#0; CommandBars.ocx

2. All vesions have different CLSID for each _controls_ inside ActiveX.

Typelib value only used by development platforms and help Visual Basic upgrade forms and project - if you have application that uses 13.0, you only need uninstall 13.0, install 14.0 and Visual Basic will automatically start using it

If you deliver application with CommandBars 14.0 to user already has another aplication that uses CommandBars 12.0  - both applications will work without problems -  Because CLSID of controls are different and compiled exe already don't use TYPELIB value.

There is only one problem with such numbering - its hard to develop 2 applications _at the same time_  with Visual Basic if one uses 12.0 and another 14.0 -  you have each time reregister version you need (for example create bat file) otherwise Visual Basic will ask to upgrade 12.0 to 14.0 on each project open. 

As alternative  we can replace TYPELIB value with each update, but developers in that case should manually replace all TYPELIBS in each project and form files of application - Visual Basic won't update them automatically.

we know that some (maybe even most) vendors (for example Crystall Report ActiveX) change TYPELIB with each version - but they  release new version once in year.  it will be annoying to replace these number for our customers with our 4-5 releases/year.

I'd prefer not to change it - for 8 years we had maybe only 3-4 complains about it, but lets discuss and poll it :)

 

oleg wrote: we know that some (maybe even most) vendors (for example Crystall Report ActiveX) change TYPELIB with each version - but they  release new version once in year.  it will be annoying to replace these number for our customers with our 4-5 releases/year.

This is the correct and professional method.

In fact, I can open different versions of projects which use different versions of CrystalReport without any problem.

 

Again: I want myself to decide IF and WHEN version may changed, or not.

 

oleg wrote: I'd prefer not to change it - for 8 years we had maybe only 3-4 complains about it

Very very bad choice, for me.

 

 

 

 

Hi,

 

@Jebo

You are right about this. If we have an option to DO NOT upgrade ActiveX controls we don't need anything else.

 

@Gibra

I really don't understand, you said you don't want to keep track which customer uses which version... How do you keep track (if you have that much VB projects open at one time) which customer belongs to opened project? btw if you have that much opened project at one time I guess you have to pay more attention to your programming skills than to this topic

 

If CJ solves this matter (not automatically update with new version unless "upgrade ActiveX" is checked) it will be fine for me and I think for most of the members. I have been in this forum for a few years now and I didn't see a post regarding this (well not in a way Gibra did)

 

Thanks

  

  

Read better. Jebo has written:

 

In fact, I disabled  this option for ALL my projects, to avoid the problem.

But the problem is still.

 

Aaron wrote:   @Gibra I really don't understand,

I see ...

Perhaps this is due to my bad english...

 

Aaron wrote:   you said you don't want to keep track which customer uses which version...

No.

I intend that I don't want keep track the CODEJOCK version used by a project.

I.e. this mean that I want use a ProjectA with 13.3 and a ProjectB with 13.4.

 

Actually, instead, I'm forced work with ONE project at time, and I must change each time the active Codejock registered version (using COM Registrator.exe) because Codejoct can't allow me to work with more than one version simultaneously.

 

Shortly, I don't want that when I install a new version of SuiteControls (i.e. 13.4) , then after this when I modify and compile a project which use v13.3 the executable NOW require v13.4, in other words isn't longer compatible with Codejock version installed in the customers.

If the project use v13.3 then compiled executable must use v13.3.

 

Really, I don't know how to explain better thic problem...

Aaron wrote:   btw if you have that much opened project at one time I guess you have to pay more attention to your programming skills than to this topic

Oh...

Very thank, I develop programs since 20+ years and I believe to know programming skills.

Perhaps, you have to pay more attention to read better.

 

 

Aaron wrote: If CJ solves this matter (not automatically update with new version unless "upgrade ActiveX" is checked) it will be fine for me and I think for most of the members. I have been in this forum for a few years now and I didn't see a post regarding this (well not in a way Gibra did)

-------------
gibra
CJ SuiteControl v: 13.x to 19.x
Windows 10 64bit
VS2019 - VB6.0 SP6
<a href="http://nuke.vbcorner.net/Home/tabid/36/language/en-US/Default.aspx" rel="nofollow">VS/VB 6.0 Installer v6.8

Jebo said:

 

@Jebo

 

 

 

btw My signature means nothing, I keep developing with new versions (maybe that's why there's a "small" post about issues in ReportControl subforum??? Huh???

 

Thanks again

 

 

Hi,

Yes as we noted in release notes. 13.4.0 just had this  problem - we didn't update CLSID. Its only one exception.  Please try 13.4.2