>>Even more simply, you can just include the Config.fpw file in the project.
>
>From my POV, that's not best practice, since it prevents creating a per-workstation CONFIG file, which, among other things, is used to direct where the temp files are placed. If you don't specify where to put them in a CONFIG file, VFP will put the in the startup directory for the app, which means that an .EXE fired in a network directory puts the temp files on the network, whcih often isn't the best choice from either an application or network point of view. Neither is a hard-coded local path, in case the target disk gets full or a cow flies by and you forget to create the temp file path.
>
>C:\ is about the only directory guarenteed to always be present, but using it is an incredibly bad move; the root directory of a drive has a limited number of entries on FAT volumes regardless of operating systems, users get upset seeing dozens of .TMP files left lying around in the root of a drive after a crash, and it just is not safe to delete all the files in the root of a drive...

I caught that (your opinion) in the other branch of the thread. (talk about mixing metaphors!) It wasn't my intention to imply that adding the Config.fpw to the project was the only solution, and you make perfectly valid points.

We use .INI's for desktop level on-the-fly application configuration and server based .DBF's for network level changes, even though special configurations are *extremely* rare.