>>
>>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.
>

Sure, but this can all be fixed with a backup. Or a re-install. And it is irrevelent to this discussion. Deleting/changing other configuration files can be detected in the EXE (if my config.dbf is tampered with, my system detects it and handles the situation). This CONFIG.FPW can probably be checked in the EXE too, but my point is that there are a lot of EXEs out there that probably don't worry about the CONFIG.FPW having a SCREEN=OFF line in them.

>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.
>

I saw a bit of the first part. That was to be used in development mode...didn't read further...

>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.

Was I referring specifically and exclusively about you?

Anyways, speaking about you specifically and exclusively, do you ever go on vacation? 'Nuff said?

>
>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.

Right. So you agree that there will be developers out there that aren't aware of this use of CONFIG.FPW? This supports my statement that there are probably many programs out there that would be screwed-up if SCREEN=OFF was placed in the CONFIG.FPW file. Are you arguing this? What are you arguing?

>>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.

Right. It is the fault of the developer. And how does that help the company that owns the software when the developer is long gone? Or even lives across town but hasn't programmed in FoxPro for years.

Ed, it is a simple point: There are probably many programs out there that would be screwed-up if SCREEN=OFF was placed in the CONFIG.FPW file.

Notice the period. I was not placing blame. I was not talking about AUTOEXEC.BAT, etc., etc., etc.. That is the scope of my statement. I think it is true. If you think it is false, just say so.

Joe