>>>How is this done?
>>>
>>>>
>>>>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?
>
>I would bet that there are applications out there that if someone created a CONFIG.FPW file with the lone line SCREEN=OFF, people would have problems.
>

Well, I can break Windows, too, with a quick change to your AUTOEXEC.BAT or CONFIG.SYS, and I guarentee that the change to break things using these files can be far more irreversable. The same applies to things like WIN.INI, the Registry, and lots of other things.

It's at least in part my responsibility to take steps to diagnose errors induced by changes like this, or by deleting a crucuial file, or editing VFP6R.EXE with MS Word. I am responsible for knowing enough about the product I use. see the whole thread on nasty VFP tricks that ran much of last week.

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.

Having to know something about the products and tools you work with is a part of the job. Being able to run through a checklist of things that could get hosed when something breaks in new and interesting fashion is a part of the job. If you don't like the flexibility offered by building a custom CONFIG.FPW per station, don't use it. There are other workarounds for some of the things like where temp files are set up (read the docs about where VFP puts temp files if you don't give it instructions) that can be used even with a hard-coded CONFIG.FPW; I just find my approach to be a better one for the applications I support. I learned about configuring VFP by being bitten on the butt by it more than once; I didn't spring from the ground at day one knowing everything there was to know about the product, much less the limited subset of the product that I know well.

>Imagine this disaster recovery plan:
>
>Step 1: Overwrite EXE. Doesn't work. Still don't see anything.
>Step 2: Recover from last known working backup. Doesn't work (didn't have an old CONFIG.FPW so it wasn't overwritten).
>Step 3: Go out of business.
>

Poorly designed recovery plan that's entirely the fault of the developer. You picked the product to use, so you need to have a clue about how it's supposed to work, and what might break it. I could make the whole machine break by putting in a squirrelly AUTOEXEC.BAT, and if the extent of your recovery plan for the system were no more comprehensive than what you outlined for your app, you'd be just as dead in the water. In both cases, erasing the affected directory before the restore would clear up the problem, without knowing in detail what went wrong.

Don't blame me, I'm just the piano player!