Steve,

All of my first level custom classes of the VFP base classes have overridden the Error() Method with this same chunk of code:

LPARAMETERS nError, cMethod, nLine
ObjError( this, nError, cMethod, nLine )

I route the error to a UDF so I can simply put all the rest of the handling in one place, that way I don't have duplicated code. The UDF at dev time puts me into debug, at runtime it logs the error to a file and shuts down the app. I generally treat errors as bugs in my code that should basically never occur when defensive coding can prevent the vast majority errors.

The UDF or subclass could easily delegate the error onto the objects parent in the UDF like this:

roObject.parent.Error( nError, cMethod, nLine )

Sometimes when I build reuseable containers of controls the contained controls all explicitly delegate the Error to the container.

This way any object I ever use grabs and handles the errors that occur with in it's methods. There is a pretty lengthy section on this topic in my PTF-OOP book. I think the object itself is usually best at understanding how to recover from errors if it can at all. If an object is going to be allowed to handle an error on it's own it's Error method usually looks like:

do case
   case ( nError = 1234 )
      * handle it
   otherwise
      ParentClass::Error( nError, cMethod, nLine )
endcase

If you used a subclass of the MAPI object you would put the code to trap the error there, instead of expecting the commandbutton "user" of the MAPI object to understand how to handle an error of another object. The reason the commandbutton's Error method is called is because your MAPI object doesn't have an overridden error method.

> In the help, it stated that Error Method will override the current ON ERROR command. Is the a way to gain control full of a command button after the error was handle? All help is appreciated.