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
Previous
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only