Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Global error routine
Message
From
04/01/2000 14:46:30
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, United States
 
 
To
04/01/2000 12:52:28
Michael Dougherty
Progressive Business Publications
Malvern, Pennsylvania, United States
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00312532
Message ID:
00312670
Views:
22
>How is error handling done in a form/pageframe/control environment?
>
>I tried to call an error handler from the form.error(), but it didn't fire when the form's control crashed. When i moved the handler to the control's error() procedure, it worked.
>
>This application is usually running after i've left for the day, and would like to record errors in a file for examination later. I don't want to have to put code in every control's error routine. (i have overloaded the form way too much to make that feasible)
>
>How can i write one error handler and have it called by errors anywhere in the form, without specifically adding the call to each control's error() routine?

Michael,
Here's an additional idea. As David F. mentioned, any code in the Error methods takes precedence over the ON ERROR. Any coded Error method in the call stack will cause ON ERROR to be ignored. For that reason, I don't use ON ERROR anymore at all--well at least hardly ever. In my start up program I instantiate an Application object, and, if I'm not testing, call ThisApp.ReadEvents(). If I'm testing, the COMMAND WINDOW is essentially our wait state. ThisApp.ReadEvents() instantiates an new object has has an error method specifically coded to route errors to the app's error object. It also has a ReadEvents method that issues the READ EVENTS. CLEAR EVENTS is called immediately before the application's destroy, so only the Destroy runs without benefit of an Error method. Why not code the Error method in the application object? 'Cause then it's always there, even during testing. Having a separate object that issues the read events is more flexible and allows me to control the global error handling.

PROCEDURE ReadEvents
LOCAL oReadEvents
oReadEvents = CREATEOBJECT("ReadEvents", This)
* Call a read events. This object may have an error method.
oReadEvents.ReadEvents()
* Now we have an Error Method in the call stack.

ReadEvents() turns off the ON ERROR trap that was started when the Error object instantiated--As I said, I hardly ever use ON ERROR--only during app startup.

Charlie
Charlie
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform