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!

how to make exe file standalone in visual foxpro5 or 6 ver

Status
Not open for further replies.

Guest_imported

New member
Jan 1, 1970
0
0
0

Can any body answer
how to make exe file standalone in visual foxpro5 or 6 ver

qviki
 
Qviki,
There is no way to create a true standalone .EXE. The .EXE that you build from a Project is nothing more than a bit of loader code (to locate the VFP runtime), and the data for the VFP runtime (identical to the .APP). The runtime "interprets" the data and that is your program running.

While I once saw a kludge described that "piggybacked" the runtime files on to the .EXE and then added some code to trick the loader into using this embedded code, the code file was HUGE. Of course if you had two applications both of them would have to carry around this duplicate code. (This doesn't even go into the legal implications that such a kludge would get into.)

Rick
 
I wan to give a programe for demo to some one. But that person has not VFP in his computer. How can I give him stand alone EXE file which could run in windows. In foxpro 2.6 I used to use these
commands

BUILD PROJECT .....
BUILD EXE FROM PROJECT FILE (STAND ALONE)

WHAT IS THE SUBSTITUE IN vfp CAN ANY ODY ANSWER IT TO DAY IT IS CAHHALNGE QUESTION AND HELP LOTS OF US

 
QW,
While you could build a "standalone" .EXE in FoxPro DOS, it has never been an available option in either FoxPro for Windows or Visual FoxPro.

Windows programs all depend on the Windows API, various system .DLLs and application specific runtimes. Visual C++, Visual Basic, Visual FoxPro and even Java all require runtime modules that may or may not be included with a given OS.

What's even worse is that specific applications may have conflicting support file requirements - the infamous "DLL Hell".

Rick
 
You need your program.app or program.exe, vfp6.exe and vfp6enu.dll in the same directory to run your apps. You can just copy these into the directory unless you have active X controls, which you will need to register. As long as the VFP6.EXE and VFP6ENU.DLL are in the dos or NT 'PATH' for locating executable files this should work.

Wayne
 
Most of these answers are incorrect. Visual Foxpro 5, 6, and 7 all have an option to create standalone EXE files for outside use (i.e., users that don't have Foxpro). Also, you need to use the Setup wizard after compiling/building your project. The Setup wizard takes care of any and all dependencies, and steps you thru every item, even to the point of adding and subtracting specific files. I don't know where some of these answers came from, but they are wrong. I have tested this extensively, having created projects, compiled them into a folder, and copying that folder to a network, and installing from the network folder to a foreign machine.
 
This is not a question of opinion - the facts concerning executables were correctly and adequately explained in Rick's post.

In simplistic terms - no runtime files - no working executable.

installing from the network folder to a foreign machine.

By installing to the foreign machine you are installing the necessary runtime files, and which is why those executables run.

Chris :)
 
drhenry is right, in that the best way to distribute a vfp application to a machine with an unknown configuration is to use the setup wizard, it will install and register all the runtime libraries you need and any active x controls etc.

ChrisChamberlain is also correct, in that this method does not produce a stand alone executable and that the notion of a standalone executable does not exist in vfp and doesn't really exist in a windows based environment at all.

If your new to this, use the setup wizard, it makes things work!

However I often build vfp exes and simply copy the runtime libraries into the working directory of the application (as wsobers) suggests.

Ian.
 
Ian

Visual Foxpro 5, 6, and 7 all have an option to create standalone EXE files for outside use (i.e., users that don't have Foxpro).

drhenry believes a conventionally or otherwise installed VFP application is standalone.

How can I give him stand alone EXE file which could run in windows was the original question, which was answered by Rick in posts 2 and 5.

The question of the best way to distribute a VFP application only becomes relevant once it is understood that the required runtime files have to be installed one way or another.

Chris :)
 
Sorry chris, you're not making any sense could you tell use where exactly the option is to create a standalone executable in vfp 5,6 & 7?

Ian

 
Ian

The point I am trying to make is that drhenry believes a conventionally or otherwise installed VFP application is standalone.

Chris :)
 
One thing which hasn't been emphasised in this somewhat silly discussion is that while it's true that VFP .exes aren't stand alone, they *can* be all you need if the runtimes have already been installed on a system. Thus preparing a computer and installing an executable can be thought of as two separate operations. Of course, in most cases there are other .dlls or the like which are also loaded for a particular project.

But if you're just constantly adding programs to the computers in your network, it might indeed look as though you're creating stand-alones.

But I'm also wondering, can all the runtimes, etc be loaded into one zip executable? This might at least make those who want unity to feel better.

Dave Dardinger
 
Let's define the term 'standalone'. If by 'standalone' you mean a file that you can copy from 1 computer to another w/o DLLs, OCXs, runtime files, no, FoxPro can't do this. However, I doubt very much that you'll find this sort of creature these days, unlike the bad old days of DOS. I had assumed that qviki was looking to distribute some sort of application to his/her end-user. And, to all the purists out there, to the end-user, this would probably count as a 'standalone' app, since they wouldn't be aware of all the hair-pulling technical issues that we programmers face. This is what programming is all about anyways, the end-users and their convenience. In the future, I will try not to criticize other people's answers, and let us all (myself included) use a little more insight and a lot less negativity in trying to help our fellow wireheads sort a problem out.
 
Another point I'd like to make is that the Setup Wizard in VFP has bugs in it. I wanted to create a "standalone" for my VFP exe to run on another machine that doesn't have the VFP software installed, for a demo I am preparing, but it doesn't work.
1) I ran the Setup Wizard: no errors occurred. I placed the setup files in a different directory.
2) I went to test it, by running Setup, and this is what it did: It went through the setup process and then towards the end, it opens my exe , shows my splash screen but then just hangs there (it runs fine through the VFP software); it's running but my custom menu nor anything else ever shows up. I have to Ctrl-Alt-Delete and delete the system process that shows my exe is "running" (where to?).
I have installed Service Pack 5.
I am at a loss. So I'm glad some of you have had success with the Setup Wizard and have gotten a real/simulated standalones on other machines.
Any suggestions would be appreciated.
 
Aimskee,
The Setup Wizard doesn't usually fire up any programs, unless you add a post setup run option. Since many of us have used the Wizard in VFP 3, 5, and 6, and for many different applications, I'm not sure why only you would get these strange results.

1) Did you follow the Help file recommended procedures? (One step "newbies" often skip is creating a separate directory for the files to be installed, instead they use the development directories.)

2) Does the Application run correctly with runtimes before you try a Setup? (A system with the development environment installed already has the runtime files.)

3) Have you tried this setup on a different "clean" system? Most of the reason for the setup is defeated if you try it on your own development system or one that has another VFP application already installed.

Rick

Note: Since this question really didn't directly relate to this old thread, you really should have started a new one - just for future reference.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top