Hi,
Have you guys found a solution to Disp Stat in the error routine for the files that are open in private (to forms) sessions?
TIA,
Marc
We use pretty much the same approach. The procedure stores relevant info to
a table record, including the call stack as far back as 5 levels. That
gives us an idea about the flow of the execution when the error occured,
which seems to be very useful in the new OO environment. Plans are to make
it even more sensitive to the context, i. e. prompt the user for a data
maintenance when the error referrs to an index problem like "record out of
range" on ordered tables., or ignore other "innocent" errors.
A feature(?) of our error trapping routine is that it always RETURNs TO
MASTER where the application is initialized, and it doesn't cancel the
program. That makes it less frustrating for the user.
>I was curious what types of error trapping routines everyone uses.
Trapping errors properly can be incredibly useful not only in developing
your apps, but in maintaining them once they are in the field.
>
>For example, the e-trapping in my apps captures all relevant info about
the error, message, module, line number and even environment settings and
adds it to an error table. While developing this is a great tool for
determining where and how your programs are misbehaving without having to
write down the errors as they are happening. You can test all facets of
your app and then look at the errors (and you know there will be some) en
masse. This will save both time and effort.
>
>In addition, this type of e-trapping will allow you to better maintain
your app in the field. I'm sure we've all had a client call us up and tell
us that our supposedly bullet-proof app suddenly grew horns and begain
spewing profanity at them. Normally, we could only scratch our heads and
inquire as to the type of medication the client is on, but with the proper
e-trapping we can just open up our error table and find out what, when and
exactly how the error occured.
If things have the tendency to go your way, do not worry. It won't last. Jules Renard.