comctl32.Ocx version question

[Andrzejek]

In my VBP file I have a line:
[tt]Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#[blue]1.3[/blue]#0; comctl32.Ocx[/tt]

I work in a team of 7 people. 6 computers are OK, but if this one person uses the vbp file, the version (in blue) jumps from 1.3 to 1.4 on the line with comctl32.Ocx

We use Vault as our code library to check files in and out. So if this one person checks vbp file out and checks it back in, everybody else ends up with 1.4 which errors in VB6. I have to re-set it back to 1.3

Any idea of what I need to do for all 7 people / computers to work with the same version of this ocx?



Have fun.

---- Andy

A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station.

 

[dilettante]

The 1.4 indicates a newer interface version.

This seems odd because this OCX has been at interface version 1.3 for a VERY long time. Even a version patched by Microsoft for security reasons should not be incrementing the minor version by adding extensions.

I have only seen this rarely, and it was because a corrupted OCX had been manually installed.

At a guess I'd probably go to the broken PC, try to unregister the OCX, then replace it with a clean copy (1.3) and re-register that.

 

[tedsmith]

Maybe Erase all the 1.4 versions in all computers?
Are all the computers using the same OS?
I have found some Microsoft Common control OCXs don't work with Win7 64 bit and you have to use another that does the same eg. Date picker

 

[CP60]

It still looks like the one system had the KB2708437 security package from 2012 installed onto it (or installed some software which included it), and the others didn't.

The one from the security update is version 6.00.9834 (6.0.98.34):
Object={6B7E6392-850A-101B-AFC0-4210102A8DA7}#1.4#0; COMCTL32.OCX

 

[dilettante]

It does appear that interface version 1.4 comes from that security package.

Lots of earlier "attempts" at this had off-by-one errors all over the place, rendering these patched libraries dangerously broken. Quick testing of a couple of the OCXs in this package doesn't exhibit such problems though - at least not where I had found them earlier.

Another advantage of this newer package is that unlike the earlier ones it supports removal (can be uninstalled).

However as you've seen there are some frustrating implications to installing the package on development boxes. They do seem binary compatible though (again, from limited testing) so you could put these versions into your REDIST folder assuming you use the PDW. Sadly, though you get the raw files as well as CAB files, the package does not contain the MSMs you'd want for Windows Installer packaging. I don't see a new set of merge modules at Microsoft Download Center with these updates.