VB6 Project won't open on Windows 7 64 bit...

Hi,

We have a large (175,000 lines, dozens of forms and modules) reporting system built on VB6.

I am charged with testing it on a Windows 7 64 bit box that has Office 2010 32 bit installed.

I am aware that we need to recode all the 32bit API function calls, and was aware that ADO is broken by Win7 SP1, but the issue I am having is that I can't even get the project to open using VB6 on Win7.

VB6 opens ok, I am running the VB6.exe as Administrator, I have followed the installation instructions on FortyPoundHead: Install VB6 on Windows 7 and am running VB6 under XP SP3 Compatibility with UAC disabled, Visual themes disabled, display scaling disabled...

To see what's possible, I started a new project with a blank Form, then tried to add the first contropl in the components list which is MS Calendar Control 6.0 but when I do that, VB6 crashes.

The same thing happens when I try to add Common Dialog Control, Common Controls etc...

The controls seem top be registered in the right place as in the VB6 Additional Components dialog the path is c:\windows\sysWOW64

Can anyone suggest the next steps I could take to even successfully add these controls?

thanks for ny help or advice
Philip

If you are testing the application then why would you install VB6 on the machine?

There is also a very murky redistribution story around MSCAL.OCX that makes it impractical to use in VB6 programs and it isn't listed anywhere in the supported libraries lists at http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

The VB6 Redist.txt file does not list MSCAL.OCX for either limited or extended redistribution.

I believe this was always an Office control library, much like FM20.OCX. They are only meant to be used on a system where an appropriate Office version has been installed first. In such a case there is no redistribution to be done.

But even ignoring that, there were many small problems involved in deploying this library over the years. PRB: Out-Of-Date Dependency Information for MSCal.ocx covers a few that plagued one version.

Quote:

---

I am aware that we need to recode all the 32bit API function calls...

---

Not that I've ever heard of.

Quote:

---

Originally Posted by p2706

The controls seem top be registered in the right place as in the VB6 Additional Components dialog the path is c:\windows\sysWOW64

---

Can you clarify this? There is a Components dialog in the IDE but nothing called VB6 Additional Components that I'm aware of.

Quote:

---

Originally Posted by dilettante

If you are testing the application then why would you install VB6 on the machine?

There is also a very murky redistribution story around MSCAL.OCX that makes it impractical to use in VB6 programs and it isn't listed anywhere in the supported libraries lists at http://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

The VB6 Redist.txt file does not list MSCAL.OCX for either limited or extended redistribution.

I believe this was always an Office control library, much like FM20.OCX. They are only meant to be used on a system where an appropriate Office version has been installed first. In such a case there is no redistribution to be done.

But even ignoring that, there were many small problems involved in deploying this library over the years. PRB: Out-Of-Date Dependency Information for MSCal.ocx covers a few that plagued one version.

Not that I've ever heard of.

---

well, we installed vb6 in order to compile the application for running under Win7 and ensure there are no problems supporting, installing, enhancing it, and running it on Windows 7 64 bit user workstations.

All the machines will have Office 2010 32bit installed.

Quote:

---

Originally Posted by dilettante

Can you clarify this? There is a Components dialog in the IDE but nothing called VB6 Additional Components that I'm aware of.

---

you are correct, it's titled Components - I was thinking of the context menu item to be clicked when right-clicking the control toolbox within the VB6 IDE.

Quote:

---

Originally Posted by dilettante

Not that I've ever heard of.

---

so we don't need to use 64-bit Windows API Function calls in place of ones that use 32-bit memory addressing under 32 bit Windows XP?

Not only don't we have to, we can't.

As far as I know the only "call" bridge between 64-bit and 32-bit is for an application in one world to make use of an out-of-process component in the other. Well, that or fall back to window message passing or some other form of IPC.

ok, so leaving aside my misunderstanding on the API Function Declarations, and given that I should forget MSCAL.ocx for the moment, what can I do to try and get these other compnents like Common Controls, Common Dialog etc working in VB6 on Win 7 64 bit?

Quote:

---

Originally Posted by p2706

ok, so leaving aside my misunderstanding on the API Function Declarations, and given that I should forget MSCAL.ocx for the moment, what can I do to try and get these other compnents like Common Controls, Common Dialog etc working in VB6 on Win 7 64 bit?

---

Use my tool VS6 Installer (free) to install VB6 + MSDN + SP6:

Attachment 104885

Download link on my sign.

Totally free.
No XPMode, no UAC, no RunAs, no setup (just unzip), no nag screen.

Last update Version 1.5 - september 2, 2013

N.B.
About ADODB issue (application compiled on Windows 7 SP1) download this Microsoft official 'final' patch:
http://support.microsoft.com/kb/2640696

:thumb:

I'd have to agree that somehow you didn't get VB6 installed properly.

thanks everyone, we'll uninstall VB6 then re-install after a reboot then see what happens.

you folks were right, a reinstall of VB6 that I did myself solved most of the problems, and the others are minor issues like the Package & Deployment wizard looking for an Uninstall file located in c:\Winnt.

Philip