Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Global error routine
Message
De
04/01/2000 15:03:20
Michael Dougherty
Progressive Business Publications
Malvern, Pennsylvanie, États-Unis
 
 
À
04/01/2000 14:46:30
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00312532
Message ID:
00312688
Vues:
22
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
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform