Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Fatal Error When Exiting VFP6 Compiled Application
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00160696
Message ID:
00160722
Views:
18
>>>Greetings!
>>>
>>>I created an EXE of a VFP6 application on our network. I'd like to know which DLLs are necessary in order to run it on a PC which does not already have VFP6 installed. Currently, I am getting a Fatal Error, with an Exception code of C0000005, as the application is closed.
>>>
>>>The DLLs I am using are VFP6R.DLL, VFP6ENU.DLL, and VFP6RENU.DLL. I am I missing a file? This application works correctly when compiled in VFP5, however I am migrating my applications to VFP6.
>>
>>Win95 machines will need to have DCOM installed before running a VFP application; Win98 and NT 4.0 systems should already have DCOM support installed.
>>
>>I'd suggest creating your install (at least the VFP 6 Runtime portion) with the Setup Wizard rather than attempting to copy files, since the VFP runtime files also have dependencies on other common libraries (like the various MSVCRT and MFC .DLLs) which need to be brought up to date properly. The Setup Wizard should handle this for you. Guessing at file dependencies and versions is a good way to mess up an install, and in some cases, a working system. If you do roll your own and don't use a third-party product like InstallShield to manage the installation of system components, you'll need some of the facilities of the Win32 Setup API to help in copying and registering .DLLs that may already be resident in memory.
>>
>>Unfortunately, Setup Wizard doesn't address the DCOM install, which can force a reboot during the install process; you can download the DCOM installs from Microsfot's Web page. If you need to encapsulte the entire install into a single process, you'll need a seaprate install scripter such as InstallShield or the Windows Scripting Host. It's simpler to do the DCOM install before attempting to run the VFP Runtime install created by the Setup Wizard.
>
>Thanks for writing, Ed!
>
>You are making a good point. The problem with using an installation process is that I have no idea who will be running the application on the network. I have a small launcher, written in Visual Basic, which is the starting point for the networked applications I create.
>
>When someone wants to run a VFP application, the launcher first checks if the required DLLs are present on their PC, and installs them if they're not found. Afterwards, the VFP application starts to load. This works flawlessly with VFP5 but, unfortunately, not so with VFP6 (apparently).

This part is easy to deal with, and a bit of packaging can make things easier for you. Create a VFP Runtime install package with Setup Wizard, and place an image on the network. Your launcher can check if the VFP Runtime files are present, and if not, rather than copying them in place, fire the VFP install from the network image (silently if you like) via VB's Shell function or any of several API calls. I'd use CreateProcess() so that I could reliably monitor the install process via it's process handle. This not only will copy out the VFP RUntime components, but will also properly update the OLE and MSVC components for you. The install can be fired silently, without user intervention by addition of a couple of command line parameters. Silent installs can be completely automatic if the default actions for the install are acceptable or you modify the .INF file to your liking.

You can also check the DCOM status (HKEY_LOCAL_MACHINE\Software\Microsoft\OLE has an EnableDCOM registry value you can look for) and fire DCOM95.EXE the same way. Be aware that the user may force a reboot after DCOM; you might want to create a RunOnce key to rerun your launcher before starting DCOM installation.

Once the install completes, your launcher can run the application unless installation forces a reboot before returning control to the launcher.

You can also have the Setup Wizard handle registration of OLE Automation components and ActiveX controls needed by your application. Again, better than copying and registering by hand where a later version might be in place already.

Doing things right is better than fixing things that don't need to be broken...

>
>Some of our users are not computer-saavy enough to go through a simple installation process, unless it operates completely automatic. Ideally, if I need to perform an installation, I'd like to have it run itself without intervention when they click the program icon, and then automatically launch the installed application.

The Setup Wizard's install, if given the correct command line /Q options will allow this; exactly which one to use depends on how visible you want the install to be (whether a progress bar is shown, or things just run completely silently, and whether a success message is displayed at termination.)

>
>Sometimes progress is a pain if we lose the simplicity of the past. [sigh]
>
>Thank you!
>
>Michael Reynolds
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform