Richard,

>Thank you for your reply. How would you test a form that needs a group of other objects to work? What I do is write a little .prg something like this and run it from the command window
>
>PUBLIC gomyform1, goconstants, goerror, goapplicationdatamanager
>
>goconstants = CREATEOBJECT("myconstantshandler")
>* if there's an error goerror will make a messageform will display
>goerror = CREATEOBJECT("myerrorhandler")
>goapplicationdatamanager = CREATEOBJECT("mydatamanager")
>
>DO FORM myform name gomyform1
>
>READ EVENTS

myform (or more properly the form subclass it's based on) should check for the existence of any servers it needs during it's Init and/or Load, although you can only terminate the Form in Init if conditions aren't right. So the code in the class Init might look like:

if ( ! IsObject( goConstants ) )
   public goConstants
   goConstants = createobject( "myConstantHandler" )
endif
...

And that code could be encapsulated into a reusable UDF too. Now your form is intelligent enough to get itself running without the need for a wrapper program.

>... seemed fine except until 'gomyform1' is up (? until I issue READ EVENTS) I don't see my errors' info in the errormessage form that goerror creates. The errormessage form does display correctly, and its properties are correct, but it doesn't 'read' them into its controls. If the DO FORM myform line has run I do get the gory details on my very occasional <bg> errors displayed as desired in the errormessage form!
>
>As you can see from the example I therefore still get all my _form_ errors displayed as desired. However as the form 'myform' is now interacting with the 'goapplicationdatamanager' created before it and I wish to do things to that object while the form Load()s, I now cause occasional errors in the 'goapplicationdatamanager' object to view and correct - while the 'myform' is in Load() and _before_ any form has displayed!

Error handling is a whole separate design issue. FWIW ALL of my lowest level subclasses contain this code in their Error Method:

ObjError( this, nError, cMethod, nLine )

it does two things primarily. 1) makes each object the target of all the errors that occur while it's methods are running. 2) reduces duplicated code by routing the error to a UDF that puts me into a debug mode at dev time or logs the error and terminates the app at runtime.

I also think that Error handling like this is a "last resort" fail-safe item. You should defensively code around the possible errors as much as you can. The only thing that fires the error in my code are bugs in my code.

When you have an object that can potentially have errors like a Word automation class I'm working on now the class Error method looks like:

do case
   case ( nError = 1426 )
      * some OLE error, like Word closed by user
      return

   otherwise
      cObject::Error( nError, cMethod, nLine )
endcase

The case handles the errors it understands and passes the others on up the class hierarchy. I go on the premise that the object itself knows best how to handle the errors that occur in it's methods. Others pass the error onto the object's container which is ok too. And in fact that type of error propogation is easily handled in the ObjError() udf.