VFP cannot start.

[jimstarr]

A German user of my VFP9 app gets the following two error messages at program launch:

Falche Version der Ressourcendatel

Visual FoxPro cannot start. Could not load resources.

I haven't seen this before. Any ideas? Thanks!!!


Jim

 

[craigber]

Two possibilities:

- Runtime files are not installed properly
- Temp folder specified in Config.fpw does not exist or user does not have full rights to that foler

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

You may have only deployed VFP9ENU.dll, but a german windows initially will search for a VFP9DEU.dll and VFP will errer "Visual FoxPro cannot start", if that is not found.

While you're at the runtimes, also check you deploy the correct SP version of all runtime dlls, not only the resource dlls with language specific texts.

Bye, Olaf.

 

[Olaf Doschke]

It should be VFP9RDEU.dll.

And a fast fix is to start Your exe via:

...Your.EXE -L"C:\Programme\Yourapp\VFP9RENU.dll"

As you will have provided the VFP9RENU.DLL at minumum, otherwise also your english customers would have the problem.

Bye, Olaf.

 

[jimstarr]

Thanks guys.

The Inno Setup install I use for this app seems to work fine all over the world. At this particular installation they installed the program with full administrator rights. I don't have details yet but they now notice that another (different) VFP application is installed at the site. Could this be the culprit?

 

[Olaf Doschke]

Well, even if the other app installs vfp9r.dll into system32 vfp searches for the runtimes in the program directory first, so put vfp9r.dll and vfp9renu.dll and all the other locale specific dlls side by side to your exe and it will use those.

That doesn't depend on Installshield, Windows Installer (which install shield uses in the end) or the other VFP application.
Creating a setup with Installshield does not automatically add all locale specific dlls, for example. It's up to you to do that.

Bye, Olaf.

 

[Mike Lewis]

Creating a setup with Installshield does not automatically add all locale specific dlls, for example. It's up to you to do that.

And it's exactly the same with Inno Setup, which is what Jim is using.

Jim, you say the Inno file works all over the world. Does it include all the locale-specific resource files? Or do you have a separate Inno file for each locale?

Either way, it will need VFP9RDEU.dll for Germany, just as Olaf says.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Thanks Mike, I overlooked Inno Setup.

I digged a bit deeper in the docs:

When the run-time application starts, Visual FoxPro searches for a resource file, first according to the L switch and then according to the Registry setting. If neither of these settings specifies a locale-specific resource file, Visual FoxPro uses the current system (Windows) locale to dynamically construct a DLL file name. Therefore, if the locale-specific resource file for your application matches the system locale on the user's version of Windows, you don't need to explicitly specify the resource file name. However, it's always safest not to rely on the system default if you want to be sure that the proper file is loaded.

As you seldom wil provide a start link with the -L switch, and won't have a language specific registry setting, the mechanism of determining the needed resource dll via the windows locale is used by VFP. I also think VP reverts to the VFP9RENU.dll, if no other dll is found, but on the search of the VFP9DEU.dll the runtime may find the one from the other VFP Application, which has a different VFP SP Version, most probably, and therefore that fails.

Something like that could happen. Which explains why it works most of the time almost everywhere.

The best thing to do really is to not install the vfp runtime centrally. The vfp runtimes better are stored right to the exe, where they are searched first. This avoids any problems with concurrent foxpro application installations.

Bye, Olaf.