Coding in different Windows versions

[krtxmrtz]

I sometimes work on a project at different computers, home desktop, office desktop or laptop and they all happen to have different windows versions: WinXP, W7(32) and W7(64). I often find that after I have worked on a computer and saved the changes, I then can't open it on a different computer unless I edit the project file vbp with a text editor and modify some object references, for example, in:

Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX

I must change 2.1 to 2.0 when back to XP and then all is fine.

This is becoming a bit of a nuisance and I wonder if there's some alternative option.

[Bonnie West]

One simple workaround you could try is to make a copy of the VBP file and edit it so that it works in XP. However, I think the better solution would be is to update all systems' MSCOMCTL.OCX to the latest version.

[Yowser]

Hi

It's a reference to the registered typelib for the control. Look in the registry at My Computer\HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1} and you'll see how 2.0 and 2.1 correspond to your problem.

The correct way would be to bring the controls in line on all versions of windows you use, which may well not be practical.

There may be a work-around, although I've not tested it so be careful! In the registry if you have an empty or missing 2.0 branch you could try exporting 2.1 branch, editing it, and importing back under the 2.0 branch. Or vice-versa: if the 2.1 branch is missing or empty (shouldn't be empty), export the 2.0 branch, edit it and import into the 2.1 branch.

My XP has a 2.0 branch that's empty and 2.1 branch with the registration info in it. This is the edited version of the exported 2.1 branch with the 2.1 changed to 2.0 ready for importing.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0]
@="Microsoft Windows Common Controls 6.0 (SP6)"

[HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0\0]

[HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0\0\win32]
@="C:\\WINDOWS\\system32\\MSCOMCTL.OCX"

[HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0\FLAGS]
@="2"

[HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}\2.0\HELPDIR]
@="C:\\WINDOWS\\system32\\"

As always be careful when editing the registry. If you're unsure, don't do it!

Cheers

Yowser

[Nightwalker83]

That is interesting! I never thought of the operating system being a problem as long as it had all the same components the project needed on it.

[dilettante]

Microsoft has historically managed to avoid breaking binary compatibility in most of their components meant for use in VB6. Where they do, they often pave over it by implementing multiple interfaces with separate typelibs for downward compatibility (which is why you see "multiple ADO versions" even though there is actually only one on a given system).

In recent years this philosophy has gone out the window bit by bit.

As far as I can tell the correct "fix" for these design-time issues is to install the newest interface version of such libraries on your dev systems. I have MSCOMCTL.ocx version 6.1.98.34 here, which has the 2.1 interface.

Of course it has to be installed right.

As far as I can tell there were some patch deliveries installing this version as part of an Office update that failed to register the library correctly, but I never had a problem. From what people have reported it seems to be a flaw in updates to Office 2007 and later. I have Office 2003 on my systems, and I got the patch without incident so I suspect the Office 2003 patch was done correctly.

Also see Fixing the Microsoft Windows Common Control Library (MSCOMCTL.OCX) Security Update

If you read to the end, it points you to:

MS12-060: Description of the security update for Office 2010: August 14, 2012 for a fix.