>>The result changes a lot:
>>i catch the error, write it on MY application errors log file,
>>kill the procedure/application and out a message in italian language to my customer.
>
>No, you still get an error that you can log. However, if the application is properly designed, then this doesn't occur at all.

Designed or debugged? The last time I saw this was when I had accidentally dropped wrong table. The problem here is not that my code has done something wrong - it happened outside of the code. And there's no way my code could have caught every possible error of this kind. Any command which requires an open table will fire up the open file dialogue, without firing any error at all... until the confused user presses cancel. What if user doesn't press cancel? I can easily imagine an user who understands that the app wants a dbf file, so he may find one and the app will be merrily going its own way until it discovers that something's wrong with the currently selected alias. The error which happens then will make an interesting log entry.

Now what I'd like (i.e. I'm with Fabio on this one) is to have error 52 ("No table is open in the current work area.") happen immediately, without showing the file open dialog... so

Set Fileopendialog Off

...is what I'd like to see. With a shorter name, though :).

>>A professional application it can not output to the customer a strange english dialog for search a table;
>>the result is that my customer it takes the telephone and it calls my company for knowing what to make.
>
>However, if you properly design the application, you don't get phone calls at all. You're relying on a feature to do the work you should be doing.

I think an error we could catch without any dialogue presented to the user would be easier to fix than the one that involves user's intervention.

I've seen things happen beyond any possible control of the application, like files being closed by network (by connection timing out or by a sloppy network admin). An error log entry I would write for such an occasion would be far more helpful in troubleshooting than when users call me and say "it wants to open something and I don't know what". Even when I was shown such a situation, I didn't know what the hell was happening - because the file open dialogue doesn't give any useful debugging information.


>VFP has no control over the dialog it presents. It's a part of the Common Dialogs dll. How do you expect the parser to respond? It can't in the midst of trying to interpret the code switch directions.

Oh, it has - before it presents it. It has a choice of presenting it or not. Or, at least, I should think we should be able to preset that choice.

>>Now, with all due respect, I’d say that the problem isn’t with the way Visual FoxPro handles this, but rather with the underlying design of your code. It’s a “best practice” if you wrote your code defensively. In other words, since you’re aware that the problem exists, design the code accordingly.

Fabio's examples look funny and simple to fix - but I think only Stephanie got his intention right. Of course we'd write defensive code where it makes sense and whenever we are doing something that may not succeed - but writing tons of defense code for exceptions like the ones I described above... it would be equivalent to obfuscating the code, manually. Instead, error 52 can be handled by a general practice error handler, which doesn't require any extra code. Except the bit of code in VFP core, which would read the setting, and decide not to display the dialog first, but rather raise the error immediately.

Besides, imagine this scenario: your web server side COM object gets hit by a hacker attack. System starts behaving less-than-perfect under stress, and somewhere you lose a file handle. It just closes a table on you, between two commands. Your code tries to do a scan-endscan or just a locate. You get a piece of GUI where you couldn't expect it - but your code is stuck, without any of your doing.

Sorry the disagree with you, pal, but this is where I think the tool can be perfected to suit us even better.