Kenneth

>From doing that I came to an unorthodox approach: Reduce or eliminate code in "automatic" events.

Not so unorthodox, actually. It's an approach that's been advocated. I'm a believer even if I do rarely adhere to it...for whatever reasons, sometimes laziness, sometimes legacy *g*.

> Maybe I'm dumb, but I just could not handle the complexity; I much prefer a simplified solution. For instance, if an object contains INIT code, it may fail. 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

Then to do a bunch of processing in the parent (?) object. IAC that's going to lead to tight coupling, which is usually a Bad Thing (tm) in OOP. But I'm probably missing a subtly.

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.

> It can also get very sticky when you've got When, Valid, OnFocus, LostFocus, and so forth on controls. The events there tend to fire back and forth. Maybe I'm dumb, but I could never quite untangle it, so the controls have no valids; when the user saves the form the entire form is validated, and a list of all problems is displayed. Users seem to like it better and it is MUCH easier to code.

I'm not discounting that your solution works for your users...I've used it myself, tho' not happily, but I think you've take a sound idea...keep code out of native events to an extreme that may be causing a lot of just different kind of pain. Again, it's cool it works for you, but I think your ideas bear discussing.

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.

Also, I'm not sure how you would handle needing to do something quite simple like handling _DBLCLICK for combos...they need a slower speed to be really searchable than the system DBLCLICK and the "best practice" is to set it in the gotfocus and reset it in the lostFocus. This works really well, and I dont' think one should be shy of using it.

The other methods you mention _are_ tameable, though. And it's quite reasonable to locate code in an init, or valid, or GotFocus. They do tend to fire in predictable patterns. If they aren't then the code has probably grown past the programmer's understanding of it (that's just an occupational hazard).

>Just my $.02

Fair 'nuff. My .02 USD back. :)