Sylvia,

>After re-reading the entire thread including your responses, I thought you were suggesting using the Error event of the Listbox class, but given what you say below, now I'm not sure. I like the idea, however, the code I have which makes the attempt to create the object is a method of the form class, not the list box.

I must have misread that you where using the Click() event of the listbox to launch the other form. Put the error handling code in the Error() method of whatever object can cause the error.

>I did want to ask you about what you said earlier. It sounds like you don't need to necessarily do the local error business Ed recommended because aftering closing this class, the error routine reverts to the original. Is that correct? Of course, given that I have a large form class and other errors can occur while I'm in there, perhaps it is safer to do what Ed is suggesting.

I'm just mildly opposed to global anything. I think it's best to encapsulate code to objects. I use an ON ERROR, but the only errors it will ever get are for the dozen lines of code that it takes to get the app up and running, after that all errors will be sent to Error() method of the objects in the system, because ALL of my lowest level subclasses have an overridded Error() method of:

ObjError( this, nError, cMessage, nLine )

ObjError is a udf that further decides what to do with the error, which may fire up the debugger, terminate the app or delegate the error onto another object. In the case we are discussing I'd override the form.Error() with something like:

if ( nError = n ) && whatever error happens because the createobject failed
this.mlNoForm = .t.
return
else
cForm::Error( nError, cMessage, nLine )
endif

The last message was to point out that when you provide an overridden Error() method anywhere in your class tree that it will supercede the ON ERROR handler, and thus has the potential to break any code that relies on the ON ERROR.