This sounds like a "Good" practice.

Glenn

>If you build an EXE or App, all your programs, classes, etc. are in the EXE file. You don't need a path for them. I use a property manager that reads an INI file to know where the data is. I never use a path for production apps--I do use a path in development. I want to be able to type o = NEWOBJECT("whatever") and have it work in development mode. In the application, I have code like this:
>This.DataDir = IIF(VARTYPE(ThisApp)=="O", ThisApp.GetProperty("DataDir"), "Data\")
>ThisApp.GetProperty() hands off the work to the Property manager to determine the location of the data. The user should be free to locate the EXE or the data where they want.
>I open tables with USE (This.DataDir + "YourTable") or SELECT (This.DataDir + "YourTable") AS YT INTO CURSOR Temp
>
>
>
>
>>I could use some help with path management in distributed applications. My applications usually launch via a startup.prg which contains a couple of statements like this:
>>
>>set default to \foxpro\rtp_new
>>set path to .\data,.\programs,.\reports,.\forms,.\classes,.\menus,..\classes
>>
>>This works fine on the development machine. However, when the application is compiled, distributed, and installed by various users, it may not reside in the "\foxpro\rtp_new" directory and the set path to statement will generate an error if the user has installed it somewhere else.
>>
>>I have tried various uses of sys(2003) and sys(2004) but I can't seem to find a technique that works well on both the development machine and the final user's machine unless I absolutely control where the user installs the application. Many users don't like to be told where the application must reside and so I need to find a way to give the greater flexibility. Can someone advise on the proper technique for this?
>>
>>Thanks