from .InteractiveChange and .ProgrammaticChange, and fire the validation when this property is set to .t., else just return .t. from the .valid event? I'll try both tonight, but in the meantime, if anyone has something better than these two, I'm very curious to know. TIA
>
>I have also heard people here speculate that since the .Valid event is a legacy of FP2.x, support for it might be dropped in the future. I have not seen anyone here offer confirmation of that idea from any statement of M$. If you want to move code from .Valid to .LostFocus for that reason, then for the same reason you would want to move code from the .When to the .GotFocus event. You'll also have to make sure your buttonbars handle .lostfocus code, since buttonbars don't get focus.

I remember that about buttonbars, so I stick to having a commandgroup in form's class - using buttonbars sounds somewhat abstract for me at the moment, since I've never taken time to study the examples. I remember a long thread on that, so I just want to play safe. Anyway, my buttons simply call form's methods, provided they have fixed names (SaveRec, NewRec etc). I may switch to a buttonbar tomorrow, and it will call the same methods.

Since I use this kind of hook, it doesn't matter where the local validation gets invoked from - .valid or .lostfocus. After all these years I've got so used to Valid (one of my favorite pets), but then the name of the method where it gets done is irellevant - I just want to have values validated on the spot, and once more in the SaveRec method (in case user skipped some mandatory fields by clicking around).

>Access doesn't have .Valid or .When events. I don't know about VB.

Poor guys :). The probable reason for the "valid goes into legacy" is probably that it's much more restrictive than it was before - under FPx, it didn't fire in some occasions (like pressing Escape or timing out) and now I've had several situations when I've had to kill the task since I couldn't exit the form because of a stubborn valid.

The issue of moving .When into .GotFocus smells like we'll never have much chance for cooperation between controls - the control receiving the focus is completely unaware of the previous control. Look at this part of the log:

form.navbuttons.cmdexit.When()
form.txt1.LostFocus()
form.navbuttons.GotFocus()
form.navbuttons.cmdexit.GotFocus()

The only event from the control receiving focus which fires before the other one loses it is its .when - and that's my only chance for a control to know which control was active before it, or for the control losing focus to know who's receiving it. Ok, I can always have some kind of FIFO stack of properties on the form, holding reference to the last five active controls or something like that, but it sounds like overkill.

Probably the best way out of this labyrinth is to take time and code total independence of each control - all of its events should be able to react properly, no matter how unaware they are of other controls. James Edgar just gave me a good idea in that direction, comparing with old value should simply be enough to decide whether to validate or not, and the object shouldn't object or even care what hit it.