Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Global error routine
Message
From
04/01/2000 15:03:20
Michael Dougherty
Progressive Business Publications
Malvern, Pennsylvania, United States
 
 
To
04/01/2000 14:46:30
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, United States
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00312532
Message ID:
00312688
Views:
24
I'm not as solid with VFP's OOP as i should be, let me paraphrase, and please correct me: the main program is creating a ReadEvents object, whose job it is to establish an error handler and a wait state. I'm very confused by the procedure name ReadEvents, the class object ReadEvents and the VFP command Read Events. please explain

*** begin quote ***
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.
*** end quote
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform