Thanks for the wish number. I have placed my vote. Not a show stopper for sure as I do program defensively but hopefully it will be implemented in the future to improve runtime behavior when bugs do get through testing or when someone deletes a critical file. If the open file dialog even indicated what file it was looking for, it would be less of an issue to me. In cases where I have seen this in the past, the user could have probably determined "so that file I deleted really was needed".

>Good news, Elmer - there is already a Wish list item.
>
>Go to Wish list #581 and register your vote. There may even still be time for the VFP Team to fit this one in (if it's not already in VFP9 now).
>
>cheers
>
>>I have stayed out of this argument, but have to agree with those who see this behavior, though well documented, is a PITA and absolutly useless in locating the error for bug reporting and debugging. The OPEN File dialog doesn't even indicate WHAT FILE IT IS LOOKING FOR. It is totally confusing to the user, whether it was caused by a lazy programmer, inadequate testing, network failure, deleting a file that was not supposed to be deleted, missing ocx or whatever. The user cannot tell tech support what file it is even looking for. About the only use for this that I can see is to save some typing at design time for an immediate query or result set where I know what the context is and what file I should select. A setting to disable these dialogs at runtime would be a good wish list item and could prevent user confusion and throw an error that could be located easier during testing or otherwise than currently available.
>>
>>
>>
>>>>>They could even implement it so that if it is in a TRY section of code then it would report the problem rather than emitting the dialog. That way no one's OLD code breaks EVER as a result of the improvement.
>>>>
>>>>
>>>>Actually it would break this VFP8 Code:
>>>>
>>>>

>>>>Try
>>>>   Select * from ?
>>>>catch
>>>>...
>>>>

>>>>
>>>>I don't know if anyone is using that feature at runtime anyway, but it would break it....
>>>
>>>Jeez, I suppose the code would break. On the other hand I suppose I could argue that the CATCH should have code to handle the unexpected error and that it would be handled there.
>>>My thing with depending on the Open dialog is that it tells the poor user NOTHING so such a dependence is truly the programmer abdicating his/her responsibility and, as you say, causing a call to support for sure. In other words, that some programs **may** be written to WANT the Open dialog to appear in the instance FabioL cites is VERY VERY UNLIKELY (to the point that such a programmer would deserve the changed behaviour) IN THE REAL WORLD.
>>>
>>>Jim