Nancy,

>
>> You now have to check for that and handle it. I found it much easier to keep INIT empty and always let an object load, then determine if it could do its job. <<

>Hm. I don't agree with this strategy. I'm not sure why it's worse to check
>

LOCAL OX
>OX = NEWOBJECT( blah, blah, blah )
>IF VARTYPE(OX) = "O"
>ENDIF

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.

Nevertheless, once I adopted that strategy, I found it worked just as well for forms as well. The simplest I got was to use data-driven opening of tables in the LOAD, which then set a flag for INIT to find if there was some problem in opening. This required that no other controls have INIT code, which to my delight worked just fine.

>
>IAC it's useful to avoid putting code in the base events of a subclass and instead use a hook pattern in the parent. So, your parent textBox, for example, might do some stuff in the init() and then call PostInit(), a custom method empty in the base class. Children can put initialization code there and not have to worry about overwritting parent code unintentially.

Agreed.


>For example, I really am annoyed when I've filled out an entire form on a website and it's not til I've hit Send that I find I've made a mistake in the beginning. Now, there's pretty good reason for web pages to operate like that, but not so good reason for us to not help our users as they go. But that's a style issue. <

I am just as frustrated with those pages, especially the ones that don't return the data I've already entered and make me fill it in again. But that's a completely different discussion. We folks who know how to write real apps will have to get into the web biz and plug the gap :)

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.

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