Information générale
Catégorie:
Gestionnaire d'écran & Écrans
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
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement