1
votes

In my VB project we use MSCOMCTL.OCX of version 6.1.97.86 and in the vbp file reference will be like

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

When this project is opened in windows 8 or pc having MSCOMCTL.OCX of version 6.1.98.34 the vbp file upgrades to Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; mscomctl.ocx

Now when this project(having 2.1) opened in pc having old OCX file error comes as MSCOMCTL.OCX could not be loaded.

The solution was to edit the vbp file and change 2.1 to 2.0 and open the project. It will solve the problem. But i want to disable the upgradation of these ocx files.In so many forums this was discussed before and to add NoControlUpgrade=1 to vbp file as mentioned here

I tried the same but it didn't work.Even after adding NoControlUpgrade=1(also verified that Updated ActiveX controls is unchecked) the projects gets upgraded when opening in pc having new ocx version and vbp file changes to Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.1#0; mscomctl.ocx

So why this solution not working? Is there any other solution for the automatic upgrade? Please help me on this

EDIT:

Below is the complete vbp file which has the problem

Type=Exe
Form=Form1.frm
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#C:\WINDOWS\system32\STDOLE2.TLB#OLE Automation
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; mscomctl.ocx
IconForm="Form1"
Startup="Form1"
HelpFile=""
NoControlUpgrade=1
Command32=""
Name="Project1"
HelpContextID="0"
CompatibleMode="0"
MajorVer=1
MinorVer=0
RevisionVer=0
AutoIncrementVer=0
ServerSupportFiles=0
CompilationType=0
OptimizationType=0
FavorPentiumPro(tm)=0
CodeViewDebugInfo=0
NoAliasing=0
BoundsCheck=0
OverflowCheck=0
FlPointCheck=0
FDIVCheck=0
UnroundedFP=0
StartMode=0
Unattended=0
Retained=0
ThreadPerObject=0
MaxNumberOfThreads=1

[MS Transaction Server]
AutoRefresh=1
1
It ignores you because it can tell that your program is not going to run if you try to use 2.0. This has something to do with a security update of either Internet Explorer version 10 or Office 2013. You'd have to get rid of it to restore your machine back so 2.0 can work again. Running VB6 in a virtual machine is bound to happen sooner or later, you might want to consider sooner.Hans Passant
Here's a guy with a very similar problem although he makes it sound backwards.Hans Passant

1 Answers

0
votes

I have seen the same problem in our environment. Our (band aid) solution is to make sure we never distribute the VBP having the 2.1 reference in it. We keep the VBP file in source control of course, and always use the check-in step as a chance to compare and catch this issue.

(As a general practice, we do not ever blindly accept any changes made to the VBP by VB6 itself. Normally I carefully diff and merge into source control only valid changes).

As an alternative, you might attempt to downgrade your MSCOMCTL.ocx on the machine with 2.1 to the 2.0 version instead. This may prevent the VBP modification from occurring in the first place.