David,

If you have read all my messages in this thread, you will see that I have suggested something like SET OPENDIALOG ON/OFF as an enhancement wish. With the default being ON, with todays behavior, and OFF triggering an error, everyone would be happy. And I honestly don't believe this is more than a few minutes/hours work to add to VFP. AFAIK VFP internally is also OOP, so it is simply a matter of changing the AutoOpenDialogTrigger method or whatever it is called internally to check for the new system variable. If is it 1 (ON/True) then show the open dialog, else throw an error.

By the way, I beat you by two years in programming experience :-)

>Tore,
>
>>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?
>
>It is the behavior the language has, therefore this is not a bug, and therefore currently it doesn't trip any error mechanism.
>
>You desire to see the behavior changed. That qualifies as an "enhancement request" the wishlist can be used to place your vote on the issue. I'm not saying that you should request this change.
>
>Personally I don't need it to change, so I abstain from voting for or against it.
>
>But those of you that want it changed have to realize that there are in fact out there apps that probably depend on VFP continuing to work the way it does. And the developers that use this feature would scream just as loudly that it must not be changed. So the change would have to be conditional. I'd also lay odds on this being a pretty low priority change despite the amount of furor that has resulted in this thread.
>
>>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?
>
>As said by myself and others you can write your code in a manner to check for these conditions if the customer can do such things.
>
>>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)?)
>
>Any removeable media should use checks to make sure that the resource is available. For that matter, network resources and local drive resources should also be verified before an attempt is made to use them.
>
>>According to your reasoning, how can you justify the use of the debugger?
>
>Come on Tore you can't be seriously asking this question. The debugger is used during development only, for the developer to verify that their code is in fact meeting it's required functionality.
>
>>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?
>
>I'm a pretty good programmer, I've been doing it for 29 years now. I use the debugger a lot in a RAD sort of manner, because it allows easy verify the code functionality by stepping though it and examining the memvars and cursors. When I'm happy it's working as expected I go on to the next piece of code. The debugger is far better than seeding debugging output commands in the code under development.
>
>>Please take a small break, and re-think through the problem.
>
>I've thought about this problem quite a bit over the last few years. Which has in fact led to my code not ever tripping the open dialog inside a production app. I've thought about it quite a bit while posting messages in this thread.
>
>>By the way, I guess you never have got the open dialog and thought that it was not a good help?
>
>I posted in another message in this thread that I did have this code error happen in one of my apps, I went back and fixed the error in the code that was causing the open dialog to appear.