Terry,

It appears that you have missed the point entirely. When a table is called to be opened, and it suddenly does not exist, VFP attempts to "Help" the user by presenting a useless file open dialog that neither explains what file it is looking for nor where in the program execution it encountered this error. The file open dialog allows the user to blindly select any table or file or cancel and then only generate an error when they selected something incompatible with the following code. Certainly if we code a command that expects a table to be open and we do not open the table first, it is a coding error that should have been discovered by proper testing. However when a system table exists when installed and some IT Nazi deletes it in the name of cleaning up trash or a user inadvertantly moves a file, it should generate a trappable error that does not display a confusing file open dialog that allows the user to select just any file. This behavior is a carried over "feature" from the days when Xbase was used interactively for very simple tasks where you knew the context and which table to select when presented with this dialog. In VFP, this "Feature" was never effectively implemented as the dialog doesn't even show which file it is looking for, effectively propagating unpredictable data errors downstream. If it generated an error, the error handler could do its job and prevent further data errors, stop it in its tracks, and allow locating and reporting it as the bug that it is, no matter whose fault it is.

No one here is asking for VFP to hide errors in their code, simply to have a set command to allow proper handling of an error when it occurs and not propagate crap and corruption by allowing the user to blindly select any file when it is clearly an error in either logic, coding or missing file.

Many will say that defensive coding will prevent this from occurring, but I doubt that defensively coding in every place that this can happen is possible or even desirable as it can really slow down execution.

Just my $.02







>>Tell us again how you handle these occurrences in your code such that your does not exhibit this bug (as you call it).
>>
>
>on error do errhandler?
>
>Are you saying that VFP should not report errors - or are you saying that VFP should not report errors when it suits a particular vanity related misnamed, mislocated files (those are errors/bugs too, No?)
>
>It seems what your saying is "I deleivered a program to a user but forgot something and now the damned program is broadcasting to the user that I forgot to include something in the delivery"
>
>Lets say you implement the "SET OPENDIALOG OFF". Then what happens? The file is not available - so any downstream error that rears its head because of the missing file is a legimate error?
>
>Do you want VFP to hide your mistakes from your user and yourself? Are you searching for a "plausible deniability".
>
>Jim - this sure seems like denial to me. It also seems that VFP is being asked to participate in a conspiracy to pretend an error did not occur.
>
>An application bug is a bug - fix it - we need to make sure we don't give our prospects (and their hillbilly IT teams) any fodder for negative attitudes regarding our development platform. We've been going through that for years.
>
>Fix your bugs - do ask VFP to help you hide them!:)