Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Using legacy VFP 6 program with Windows 7

Status
Not open for further replies.

tkee

Programmer
Feb 6, 2004
55
0
6
US
We have an old program we need to use for one department. We do not have the source code. It was written in VFP6 and runs fine on our old XP computers. However, we have to upgrade everyone to Windows 7. The EXE throws Error 11 (Function argument, value or type is invalid) and gives the program and line number. I can run the program on my Windows 7 PC with no error, but I am a developer and have VFP 9 installed on mine. What would be different on Windows 7 than XP or Windows 7 with VFP installed? Are there some support files or updates that are installed when installing VFP 9 that are needed to run the older legacy program? The Windows 7 machines are set up identically other than having VFP 9 on mine.
Thanks for any insights.
 
It's pretty difficult to answer this question without seeing the code that produced the error. I can only suggest that you contact whoever wrote the application or has a copy of the code. If that's not possible, a temporary fix would be to run the application under Windows XP in a virtual machine on the Windows 7 computers, but clearly that's not a long-term solution.

In general, given a VFP 6.0 program that runs correctly under XP, there's no reason for it not to run under 7 as well. It's unlikely that any of the support files (I assume you mean the VFP runtime library) are not installed, because, if that was so, you probably wouldn't be able to launch the application in the first place.

Also, the fact that you have VFP 9.0 on your machine is probably a red herring. Given that you don't have the source code, I assume that you are running the built application, just as it would run on any other Windows 7 machine. The presence or absence of VFP 9.0 runtimes shoulnd't make any difference.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Thanks. I was afraid that would be the answer. We have no way of accessing the source code. We just can't understand why it would run fine on one Windows 7 PC and not on another.
 
The biggest issue with running an app on Windows that ran fine on XP is permissions, especially, if the app is running from 'Program Files'.
My first suggestion if you haven't already, is to create a directory/folder off C:\ with "Full Access" permissions and run the app from there. See if you still get that error.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
As I understand the program runs fine on one Win7 PC but errors on another. Could it be that some international settings in Control Panel of Win7 are different. For instance a comma or a point as decimal sign, or the way times and dates are presented. Or the currency...
That the error occurs during a conversion of external data?
 
Hi,

This can be a nasty long story.
I would advise you to buy Refox, decompile the exe and have someone reconstruct the the application for VFP9SP2 and built a new exe.

Sounds like a lot of work, but could be fixed in a day or 2 and you are done for the next generation.

Jockey(2)
 
We just can't understand why it would run fine on one Windows 7 PC and not on another.

That's the key point. You've got to figure out what's different between a machine on which it runs, and the one on which it doesn't run.

One approach might be to start with a virgin Windows 7 machine: one on which you have installed the operating system and any other essential components - and nothing else. Install your application (outside the Program Files tree, as per Dave's advice). Make sure all the important control panel settings are normal for your environment (as per Jack). Then install and run the application.

Assuming that works, start adding the other applications and components that you will need for day-to-day use of the machine. At each stage, test the application again. If, at any point, it stops working, that should give you a strong indication of what caused the failure.

I know it's laborious, and there will be guarantee of success, but it seems the best approach in the circumstances.

Mike





__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
It will not run on the virgin Windows 7 PCs at all. We are just now upgrading and haven't been able to use it on any of them. The application is installed on a network drive. We have been unable to get it to run on any of the newer machines either on the server or installed locally. However, I was able to run it on mine with no problems. The only thing I have done differently than any of the others is install VFP 9.0 locally. I'm thinking the program must refer to or use something in my VFP settings or something that is there in my path but not on the others.
 
In that case, the next thing to try is to install the VFP runtimes on one of the other machines (one on which the program does not run). If that then works, your diagnosis will be correct. You can then install the runtimes on all the computers. To comply with your VFP 9.0 developer's licence, you might have to create an application to install with the runtimes, but that shouldn't be too difficult.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Well, the problem is identified, you have to install runtimes.

You can also put them in the share in the exe folder, because the Dlls/Exes ostly need no registration. If you use CHM you need to register foxhhelp9.exe.
And you don't need to make an installer to distribute the runtime Dlls legally, the files are present aside of the merge module in you common files folder at your development machine. What you can't install legally is vfp9 itself.

About runtimes see
Another argument for putting specifically the vfp9r.dll to the exe is: It's not necessary to register vfp9r.dll, if it's put in the folder of the exe.
BUT: The DLLs are better not used by multiple users in the share, that causes trouble and network bandwidth is wasted. DLLs are not just loaded once and then you're done. Therefore create a copy job, copying only newer files, including your EXE and the runtime, and you will copy the runtime only once, but also can update it to SP1 or SP2, if you don't already use them. Also you only will have network traffic for data, and the EXE and runtime files are only once copied at each first run of each new version. XCOPY has such a "copy only newer files" flag. Robocopy, too.

Bye, Olaf.
 
Olaf,

That is strange you advise to install VFP9 runtimes to get an exe compiled with VFP6 running?
I have not yet had that experience, I would advise to install the VFP6 runtimes. And as far as I can remember VFP6 had many updates, I believe upto SP5, it could also be possible that the runtimes of a different SP will not correctly work with the runtimes of an other SP.
I still believe it is better to recompile this old exe and rebuilt it in VFP9SP2, some work which will garantee at least for the next 10 years your application will correctly work.

Regards,

Jockey(2)
 
Jockey,

I also advised the installation of VFP 9.0 runtimes. I don't normally like advising a fix that simply avoids a problem without attacking the underlying cause. But, in this case, Tkee has clearly stated that the application runs correctly with VFP 9.0 runtimes installed. Although I can't explain the reason for that, the priority is to get the thing working, so I stand by my advice.

Also, you suggested re-installing it with the VFP 6.0 runtimes. But if these were present in the first place, I would expect the app not to run at all, rather than to run until it reached an error message.

You made a good point about the multiple service packs for VFP 6.0. It's possible that's related to the problem somehow. If he had access to the source code, recompiling it would be a good move. Then again, if he had access to the source code, he could figure out where the error was occurring, and thus know exactly what was causing it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Well, the same that applies to this wiki entry applies to VFP6 runtimes, there is just no topic about that in the wiki. VFP6 has a few less runtimes, as it does not make use of MSXML and gdiplus, but otherwise replace each 9 with a 6 and you have the same topic for VFP6 runtimes, roughly.

Bye, Olaf.
 
The runtimes for VFP6 have always been installed in the folder with the exe. The exe works in XP on all PCs without any additional setup. We also tried installing the VFP9 runtimes, which made no difference, so we removed them. The error is actually in the code I can't access. It apparently refers to something that is set differently on my Windows 7 PC only. Unfortunately that doesn't really narrow it down much. Thanks for all your replies.
 
Another thought: Have you considered running the app in XP Mode under Windows 7? Or in a virtual machine?

These are not ideal solutions, but if you are really stuck, they might just get you out of the fix.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
If it's not the runtimes but the installation of VFP makes a difference, the EXE might refer to some of the source code samples and classes coming with VFP. That shouldn't be the case, as a build of a project should add that into the final EXE, but that's the only other thing the app might use.

One other thing you only have on PCs having VFP installed are some OLE classes. mscomctl32.ocx taken from XP to Win7 could make that run again, also there is one OLE class specific to VFP for it's search feature, a Finder.

All these things would come up as errors mentioning a non registered class. Actuall what are the errors you get from the application not working? Are error messages suppressed, perhaps?

Bye, Olaf.
 
The error is simple - Error 11 (Function argument, value or type is invalid.) It gives the program and line number, which are pretty useless without the code. It seems to be in the setup portion of the code, because the error is the only thing that shows on the screen. If we choose Ignore, it just keeps giving the same error. Nothing is installed on the hard drives of the XP machines running it, everything is in one folder on the server. It has been running for years with no problem. They do use old scanners with the program, which we have anticipated might be a problem. I wonder if there could be a referral or some type of setup to them there - but it still doesn't explain why it works on my Windows 7 PC and no others. I have never appreciated having source code so much before.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top