Hi Brian,
I know what you mean. :-)
I'm sticking by this point: Paths are for developers, but not for applications. Many developers use the SET PATH during developement, because they want to set in the Command Window and type MODI COMM MyPRG, MODI FORM MyForm, or DO FORM MyForm. They put the SET PATH statement in their main program so it's always there in design mode. I never put any SET PATH statements in my application code. I have a development ToolBar that sets the path for the project I want to work on in design mode.
So without a path, how are the data files, and any other resources not included in the project found? The application object has these various file location properties. So I can have a Tools/Options/File Locations just like many other applications have. The user can place the data files where they make sense, not where I tell him they must be.
This means I can't ever do:
USE Customer IN 0 ALIAS Cust
but instead must do
USE ( This.DataDir + "Customer" ) IN 0 ALIAS Cust
In design mode the This.DataDir property may be empty, and the path is used to find the file.
...Probably more than you wanted to know.

>Really? I need to go try this. In the past, when I've forgotten to include the folder in the set path, I've had issues, but I may have adopted this rule-of-thumb as a result of something else... humm...
>
>
>- Brian
>
>
>
>>Hi George, Brian,
>>SET PATH should be irrelevant for forms--anything that is in the project. If fact, if in your app you said:
>>DO FORM Y:\Forms\MyForm
>>and MyForm was in the project, MyForm would run, even if the user running the EXE or APP file had no drive Y:. And even if they did have a drive Y: with a MyForm.SCX file, the APP would still run the one you compiled into the APP, not the one on the drive!
>>Now, why the Form isn't found, that's something else. :-)
>>
>>