|
| Discussion | |
From: mda
Keywords: ErrHandler, Suggestion
Remote Name: 24.218.251.34
Remote User:
Date: 03/10/02
Time: 12:50
Hi Doron,
The reason I defined an API for error logging was to provide a general-purpose hook for adding logic tailored to your own application. I understand that people often want to capture error info to a DBF, but how one approaches this invariably involves a bunch of arbitrary, application-dependent decisions. Also one must take extra care that the logging itself does not encounter any errors, because of VFP's restriction against nested error handling.
Take a look at the documentation for the ehp_log_function property at http://www.ideaxchg.com/ix07/er/erhlp002.htm#ehp_log_function. This is the recommended way to tie your own error logging function into the ErrHandler classes or any subclasses or forms based on them. If you examine my errhdemo.scx, you'll see a method named ERRHCM_LogAPITest, which is a trivial function I used to test out this feature. You can substitute your own UDF for this, and assign its name to oErrh.ehp_log_function, so that your logging function will be called whenever the principal error reporting function, errhshow() is called (internally). The API specifies that your function will be called with the following arguments: errobj_arg, ernum_arg, msg_arg, title_arg, and it should return a success flag (.T. = success).
I could have created a more useful illustration of such an API logging function in my demo, but it would have been purely for didactic purposes, not truly reusable and generic, and I simply didn't have the time. You can easily do this for yourself by adapting your logging procedure to conform to the API. Note that you can use the errobj_arg to get to a bunch of ehp_... properties that you might want to record. Since the ehp_log_function is called whenever there is an EHM_ShowAppErr() / errhshow(), you can also use this mechanism to record any diagnostic tracing messages as well as error messages. It's entirely up to you what options you might want to support as to what information should be logged, and how those options would be controlled. You could modify the diagnostic message dialog to provide the appropriate checkboxes, but I wouldn't recommend that approach. Instead, I'd suggest that you avoid messing with the core ErrHandler programs, and let your own application interfaces govern your own application-dependent logging features, cleanly separating generic code from app-specific code.
Mike
|
|
|
|
| Contents | Discussion | |
|