>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

OK Michael,
The big picture is this:
Error methods allow each object to handle their own issues. If any object in the call stack has a coded error method, the ON ERROR Program is ignored. My thinking is to conditionally have an object in the call stack that has a coded error method. Whoever/whatever issues the READ EVENTS is always in the call stack. This means, for the most part, I don't use ON ERROR DO Something, but instead, use the call stack and the first coded error method handles the problem. Understand, there's nothing wrong with issuing an ON ERROR DO Something at the start of your app. It's only my preference to not use ON ERROR and try to stick to method calls.

The details for me are these:
The main program creates an application object.

ThisApp = CREATEOBJECT("MyApp")
or DO FORM MyApp Name ThisApp LINKED
If Errorhandler desired
   ThisApp.ReadEvents()
   * Now the app hangs, waiting for user input.

In the application object's ReadEvents() method, I create an object as shown above after the Begin Quote.
That ReadEvents object uses three methods: Init, Error and ReadEvents.
DEFINE CLASS ReadEvents AS Relation
   oApp = NULL   && This property will hold the application object reference.

   *************
   PROCEDURE Init
   LPARAMETER app
      This.oApp = m.app  && Store the app object reference.
      ON ERROR  && Turn off any ON ERROR routines. They won't be called anyway.
   ENDPROC
	
   *******************
   PROCEDURE ReadEvents
      READ EVENTS     && Hang around here awaiting input.			
      This.oApp = NULL
   ENDPROC

   ***************
   PROCEDURE Error
   LPARAMETERS nError, cMethod, nLine, Object
      IF TYPE("This.oApp.ErrorHandler") = "O" ;
         AND NOT ISNULL(This.oApp.ErrorHandler)
         This.oApp.ErrorHandler.Do(m.nError, m.cMethod, m.nLine, m.Object)
      ELSE
         WAIT WINDOW "Error handler is not instantiated. Error number " ;
            + ALLTRIM(STR(nError)) + "."
      ENDIF
   ENDPROC
	
ENDDEFINE
The ErrorHandler object is the standard fare with these type of template methods.
THIS.CatagorizeErrors() && Set properties based on the error number 
                        && severity of the situation.
THIS.GetUserInput()     && If there's a choice in how to respond, ask the user.
IF THIS.OKToWriteErrorLog()   && If this is an event we should log, do it.
   THIS.WriteToErrorLog()
ENDIF
THIS.Remedy()     && Act on the remedy for this error.

Charlie