>>>>>The CONFIG.FPW is usually compiled into the executable and, therefore, cannot be tampered with after distribution.
>>>
>>>Simply include an appropriate CONFIG.FPW under either Other/Other FilesOther/Text Files in your project when you compile the .EXE, and it's bound into the executable. My objection to doing this is that I can't change where the temp files reside easily without moving the location of the .EXE file and not setting the location in CONFIG.FPW or the equivalent.
>>
>>Do you see it as a problem that if you don't bind the file to the EXE, anyone with Notepad and access to the CONFIG.FPW file can add lines?

>If you like, you can bind in a CONFIG.FPW and live with the results of doing this. In my case, where I expect to have a CONFIG.FPW built to suit the needs of the target workstation, I need to know that I have to check the CONFIG.FPW on the workstation to see if it's gotten hosed when certain types of errors occur, like pointing SORTWORK to a non-existant directory, or to the overly-full root directory of a drive. when someone reports the types of things that might happen as a result of changes to the CONFIG.FPW, it's my responsibility to have the user check the CONFIG.FPW, just like if certain types of errors occur using one of Adaptec's SCSI Adapter's it's Adaptec's support people's responsibility to check if the driver or registry entries for the adapter are frobbed.

If you need to customize the application based on the user/workstation, you might be better off using an .INI file or storing the appropriate settings in the registry.