| Discussion |
Remote Name: 18.104.22.168
The demo form, errhdemo.scx, is based on the foundation ErrHandler class for forms, ErrHForm. The main program, errhdemo.prg, is just a small wrapper function that that uses DO FORM to instantiate the form.
There is no explicit instantiation to be done by an application "where an error occurs". Normally one would subclass application classes off of the foundation ErrHandler classes, primarily ErrHForm. If you have an existing application, you can redefine your forms as subclasses of ErrHForm via the VFP Class Browser. By doing this you gain the error handling features of the generic error handler facility. You would probably want to initialize some of the ehp_... properties, and override or augment certain methods, with appropriate use of DODEFAULT. See Creating an ErrHandler-Based Application for further details.
The ON ERROR mechanism is an optional feature (controlled by ehp_on_err_handle), established via ErrHForm's Activate, Deactive, and Unload methods. The point of this is to cover errors in any member objects of the form, because errors in these objects do not magically get propagated to the form's Error event. (This behavior might be regarded as a flaw in VFP's definition of its default error handling logic.)
Because of the ON ERROR mechanism, ErrHForm is the only ErrHandler foundation class that a typical application is likely to need. ErrHCustom may be used to support target indirection, which is a way of passing diagnostic and error information between application components. ErrHCustom is also useful for building applications that don't have a user interface, like my Querier, for example. I've also created other foundation ErrHandler classes corresponding to VFP's other base classes, but these have not yet been uploaded to this web site. These other ErrHandler foundation classes are useful in more complex applications, where modular control components are dynamically launched into various flavors of containers.