Hi David,

Thanks for the reply, I have read your message perhaps a dozen times and have given it much thought. At the time I didn't have much invested into the error routines. I like the idea of passing the error to the form cause if you have an error in runtime most likely you want to close the form...

In your objectbaseclass.error you call ObjError( this, nError, cMethod, nLine) is that part of your application class? Am I correct in thinking that if the subclassed object if it has no error routine it will call the baseclass.error as a default error handler. If you know that there might be a runtime error (file missing or corrupt) you code into your subclassed object the code to handle it. Am I correct so far?

How does ObjError call debug? Do you suspend in your error method if you are in the dev environment if you call debug?

Thanks
>
>No, I don't. All of my lowest level baseclasses delegate an error to a UDF ObjError( this, nError, cMethod, nLine ) At devtime it prompts to enter the debug environment and at runtime it logs the error and shuts down. For the very few cases where a runtime error is allowed to occur the object that can cause the error overrides the Error() method and either handles it itself or directly delegates it to thisform. I strongly believe in defensive coding and test for probable error conditions before they occur.
>
>In John's case I'd conditionally enable the item that allows them to start the form. If the file doesn't exist leave the item disabled. I think this approach is easier to maintain than putting lots of error trap code.