> VFP has file locations for everything else imaginable. Why doesn't it have one that tells it where to find the data? > >If it would just use the config.fpw that's in the directory, all would be well. But it seems to ignore it when run from within VFP. >
The problem is that the CONFIG.FPW is evaluated when the VFP executable is started, not when the application is started. When firing the executable outside of VFP, the internal CONFIG.FPW is examined and used to establish the runtime environment before your application gains control. That's not the case when you start VFP directly - VFP starts execution, uses whatever CONFIG.FPW is in it's search path (or is specified with -c at invocation) and then you foire your app. When the app starts, the runtime environment is established already, and the internal CONFIG.FPW isn't evaluated.
Some simple solutions:
(1) Set up a shortcut for debugging that invokes VFP with the proper CONFIG.FPW before beginning to debug. The -c switch allows the specification of a CONFIG.FPW at runtime invocation As an example:
VFP -cC:\MyApp\Debug\CONFIG.FPW
would start VFP using the CONFIG.FPW found in the directory C:\MyApp\Debug. You do not have to name it CONFIG.FPW when set with -c, for example:
VFP -cC:\MyApp\DevArea\CONFIG.DEV
would start VFP using a file called CONFIG.DEV instaed - I use this to set up multiple CONFIGs, one for production, linked into the .EXE, and another for debugging. This allows you to set up a debug environment easily.
(2) Evaluate the CONFIG.FPW at runtime. This is considerably trickier; you'd need to determine whether you're in a debugging environment (I use a DOS environment variable, and examine it using GETENV() to retrieve it at runtime) and then write a short routine to evaluate the content of the CONFIG.FPW before your app gains control. The biggest problems with this approach is that certain things can only be set before VFP starts (such as the TMPFILES directory) and you still need to find the right CONFIG.FPW to evaluate.
