>>>>But if a select attempts to open a file thats not vailable - then it is an error. If ON ERROR don't catch it - then the next best thing is OPEN DIALOG. When we test our apps and the OPEN DIALOG pops up - we should fix the error or simplify the paradigm.
>>>
>>>Terry,
>>>
>>>It is the same dialog that GETFILE() utilizes. It's simply a wrapper to the Windows API call GetOpenFileName in Cmndlg32.dll. It just supplies only the file extension.
>>
>>George,
>>
>>Then couldn't the OPENFILENAME structure be prefilled and end this controversy? ;-)
>
>Jim,
>
>Possibly, but you'd still get the dialog and there's always a chance the user selects the wrong one or cancels.
>
>Let me take the opportunity to say I'm abivalent about a switch to turn it off. It's not something that causes me a problem, and, if I had a choice, I'd just as soon work be done in other areas. If someone else thinks it's a good idea, I've no problem with that.

I'm with you - no need to turn it off, just give me an inkling what it's looking for. I've only had it once in a user app in recent history, and it was devastating to the user. "Cancel" was the wrong choice ;-) I get it often enough developing that giving me the file name is more than enough to fix the problem. Just fill the structure for me!