Hi Ed,
<i><font color="#663300">I think that the best strategy would be to replace the DODEFAULT line with the SetError() / HandleError() calls, and leave the rest as is.</font></i>
I am afraid I am going to have to disagree with you...something I have done on several occasions, but never, to my recollection, about Codebook. <bg>
The first case statement checks for DEBUGMODEFILE and executes if it does not find it. The absence of a textfile indicating my development environment in no way precludes my desire to use the error handler. I am currently adding the Stonefield enhancement to print out an error report.
In any case, my version of HandleError(), as well as the Error()method for all base classes, either finds or instantiates an error handler object and it is the object responsible for determining whether DEBUGMODEFILE is present and offering the developer a debug option from the ErrorMessage form.
In any case, the only flaw in the error system as currently implemented is that it fails if the error occurs at the form level because the form error method has no way to get to the error handler. If someone has used ON ERROR extensively, then we need a way to choose which is the appropriate way to handle the error in each case. In the latest version of Stonefield's baseclass Error and form HandleError methods, the ON('Error') condition is checked for right after searching the containership hierarchy for an error handler.
I don't understand the .lErrorVFP option. What does it get you that nothing wouldn't also get you?
Pamela
pamela at eagle-crest D.O.T com
©2001 Pamela Thalacker |
