Kenneth-

>Here we will probably have to agree to disagree, and/or I should elaborate. In the last 2.5 years or so I've gotten heavily into large processing applications as opposed to traditional form-based validated db apps. For jobs such as these, loading the object is not the problem. Rather, the object itself has to be sure it can do its job. Therefore, in the interest of a clean interface and simpler invocation code, I will usually have something like this:
>
>

>loDoTheBigJob = NewObject("SomeBigJobClass","ClassPRG.prg")
>loDoTheBigJob.SetParms(parm1,parm2,...)
>loDoTheBigJob.Main()
>RELEASE loDoTheBigJob
>

>
>For these, all failure and success messages are sent to a log. It is a different animal from a form, and I probably should have made that clear.

Actually, we're not so far off, really. There's a difference between doing reasonable things in the init (or any method) and breaking things up into logical routines (methods). So, instead of stuffing everything and the kitchen sink in the init, or refresh, or the DoStuff() method, split it up. Sure thing. Indeed, depending on what your Main() does, I'd probably split it up into verbs (I equate methods with verbs) that can be easily swapped.

I do appreciate you taking the time to explain, because I had read your other post as perhaps scaring people off the init() and I don't think that's really what you intended. Heh, knowing why we're doing something is 90% of the battle.

>I think we're deep into the realm of preference, but when I was heavily coding validated forms, I myself hated to be teased along one error at a time through the page. I figured, let the user fill it out and then give them a list of *all* errors. It worked for me, but I'm sure it doesn't work for everybody.

Right. I usually let the users have the call, though I give 'em the pros and cons I know of.

>Always nice to chat style with a fellow developer...

Yes. Thanks for the discussion.