Hi David,

You are of course also entitled to have your own opinion. But just because it is the documented behavior, does that make it the correct behavior? If all errors would have been found by regression testing, can you please tell me how I can avoid the open dialog box if my customer deletes or renames a file?

Let me give you an example: You have this line of code in your application: SELECT * FROM D:ABC INTO CURSOR cTEMP, and your customer has removed the CD with the ABC table after he started the application. Wouldn't it be nice if at least the open dialog suggested the name of the missing file (ABC)? (And triggered an error which you could trap (duck)?)

According to your reasoning, how can you justify the use of the debugger? There should never be a need for it because if you don't do as help tell you to do things, you are a bad programmer! That is in fact what you really write. And all the other debugging features are also only for bad and/or lazy programmers? Please take a small break, and re-think through the problem.

By the way, I guess you never have got the open dialog and thought that it was not a good help?

>Houston,
>
>>state opinions as though they are facts or in this case, truths (I consider one tantamount to the other).
>
>Exactly how is this an opinion of mine? From two standpoints:
>
>1) It is the well defined behavior. From the help file:
>
>Remarks
>If no table is open when using the FROM clause, Visual FoxPro displays the Open dialog box so you can specify the file location. Once open, the table remains open once the query is complete.
>
>2) The errors he was running into would have been found by regression testing.
>
>>I am in complete agreement with Fabio, Sergey, Jim Nelson and the many others - this is a flaw / bug / call it what you want, in VFP's implementation.
>
>I call it documented, defined behavior.
>
>>I do not want the User to get an occasional dialog box that I have not explicitly caused to appear.
>
>>I code defensively and rely on good architecture and testing to facilitate the creation of robust solutions - however, I cannot guarantee that I will catch 100% of the possible errors. Hence the need for ON ERROR and TRY ... CATCH. When the Open Dialog appears I am no longer in control, to think anything else is a case of being 'economical with the truth'.
>
>IIRC I stated the exact same thing in an earlier reply to Stephane.
>
>You don't see anything I've posted in this thread that prevents you or anyone else from asking for this behavior to be changed.