MYPROGRAM.EXE Always Needs the "FORMS" folder

[PabloHaughton]

I recently created and EXE file which includes forms that are located in the C:\MyApp\FORMS\ folder.
After generating the EXE and copying it to another computer, it displays an error saying "Invalid Path". After a lot of testing I discovered it is the FORMS folder it's looking for.
If I tell it to ignore the error message it works fine but it should run without displaying the error.

Has someone an idea on this?

I will greatly appreciate your help.
Thank You.

 

[alvechurchdata]

Did you actually include code which said:

[TT]DO FORM C:\MyApp\FORMS\MyForm[/TT]

Or is it perhaps looking for a background picture or icon file for the form?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[PabloHaughton]

Yes, I call the forms using "DO FORM C:\MyApp\FORMS\MyForm
"

They do not have any background pictures.

 

[JRB-Bldr]

Does your code have something like the following in it to set up the defaults?

* --- Determine Path of This EXE ---
mcStartUp = SYS(5) + SYS(2003)
* --- Set Program Default Here ---
SET DEFAULT TO (mcStartUp)

* --- Define Data Directory (or others) ---
mcDataDir = ADDBS(mcStartUp) + "Data"
mcImageDir = ADDBS(mcStartUp) + "Images"

* --- Establish PATHs To Use ---
mcPath = mcStartUp + "," + mcDataDir + "," + mcImageDir 
SET PATH TO (mcPath)

Something similar to that in the early Startup code will typically eliminate most pathing problems.

And, as Goeff suggests above, try to eliminate any "hard coded" path definintions.

Good Luck,
JRB-Bldr

 

[alvechurchdata]

Yes, I call the forms using "DO FORM C:\MyApp\FORMS\MyForm

That's what causing the problem. Try [TT]DO FORM MyForm[/TT].
You might have to use [TT]SET PATH[/TT] to tell the project where to find the form. Use relative paths rather than absolute.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

I agree with Geoff's answer, except to add:

1. Don't hard-code the path and don't issue SET PATH TO C:\MyApp\FORMS in your program.

2. Instead, use DO FORM MyForm (no path). In Tools / Options / File Locations, set the Search Path to c:\MyApp\MyForms.

3. When you create the EXE, be sure to include the forms (I'm sure you're doing that already).

If you follow those steps, you should always be able to find the form, both in the development environment and at run time.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[PabloHaughton]

Thank you all for your great assistance.
But...
The forms are accessed with no problem in the exe file.
Even though I made all the changes you suggested the exe file keeps looking for that "FORMS" path.
I've even placed an error trapping routine in the first line of code in the "Main" form to see exctly where the problem is and the error seems to happend before the ON ERROR command can trap it, in other words before the first line of code.
The only Method I'm using is "Init".

Isn't this strange?

 

[Mike Lewis]

How about checking your Config.FPW file (if any)?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[JRB-Bldr]

Here's a thought for debugging the problem....

Put your SET STEP ON just before the DO FORM <whatever> command and run your application from the Development mode.

When the SET STEP ON executes it will Suspend your application and open the Trace Window.

When that happens, go to your Command Window and enter
DO ?
That should open up a GETFILE() window.

Look at the directory which opens with that GETFILE() window. It will represent the current default directory.

Maybe some other portion of your code, sent your Default path off somewhere un-expected so that now, from here, the relative pathing will no longer work.

Let us know what you find.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

If you're going to go the debugger route, why not just set a breakpoint on Curdir() before starting the app?

 

[alvechurchdata]

I've even placed an error trapping routine in the first line of code in the "Main" form

I don't mean to ask a stupid question, but are you sure it's the first line? I once wasted days on an early VFP job until I found that my predecessor had put some setup code in the BeforeOpenTables method of the Data Environment of the main form.

The way that I discovered it was to add a BreakPoint on [TT]LINE()[/TT]. This stopped the exe on its very first line of code.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Olaf Doschke]

Hi Pablo,

typically, you shouldn't work with a form as the main file of the project, but a prg file that does some init and finally may start a main form or a menu.

The init event of a form is about the last thing to run, before activate and then waiting for user interaction. Before that all init events of controls run, before that the load event of the form and before that the Dataenvironment (DE).

A form with a DE does some things before you even have the chance to run a line of code. The BeforeOpenTables Event may be the best place, but there may even be some properties evaluated, especially if you put =someexpression() in it, that could run code even before your "first line".

A main.prg will clearly run beforehand. So in your case make it at least:

ON ERROR someerrorhandler(...)
DO FORM mainform

Bye, Olaf.