>Pretty close to what I use, but your strategy must change depending on whether you use row or table buffering. With row buffering, you would definitely want to call the field rules even when a nav button is clicked, otherwise a user could commit bad changes, and you would have no way to revert. With tablebuffering you would probably want to do the same thing, but you could wait until TABLEUPDATE() to check the fields and use GETNEXTMODIFIED().

I don't intend to have double strategies for validation - i.e. though I may have both schemes of buffering, I still plan to verify every record, though I may issue the TableUpdate() at document end, and not at every record. I mean, I won't let an user add the second line item before the first one was OK, and I'll save them when all of them are OK. The validation scheme won't change, but the save will.

>>[And finally the last chance fires. Is this the reason why all the folks here said that Valid is legacy and the validation should be moved to .lostfocus - it fires after some of the next control's methods, so we can establish some inter-control communication?]
>
>
>Actually this is not dependable. If you do some more event tracing, you'll find that this behaviour only happens when using the mouse to Navigate. The firing order changes when tabbing or using a keyboard shortcut. I found this when messing around with a form.nextcontrol property that I thought I could fill in a control's when event. Couldn't do it.

Thanks for confirmation - I had some intuitive fear that this may be the case. I won't try to use this firing (squad :) order; the chance seemed thin in the first place. Total object isolation seems to be the predestined way to go.

>
>>...etc. Now is there any better solution than to replicate the signalling code (thisform.EditingIsOn=.f.) in every nav button's .When(), and to move all the validation to txt*.lostfocus, or try another approach? I have another idea - to have an indicator property of IAmChanged on every control, and set it to .t. from .InteractiveChange and .ProgrammaticChange,
>
>I do this in my framework also. I have a method similar to your localvalid method that is hooked into the real valid method. The class' valid code looks something like (translated into your names):
>
>if !LASTKEY() = 27 AND this.changed AND !this.localvalid()
>?chr(7) && Beep
>WAIT WINDOW this.failedvalidtext
>this.value = this.origvalue && orig value was populated in gotfocus
>this.changed = .F. && I'll explain below
>return 0
>endif

I'm actually doing the same, except for resetting the .changed and .value. These two are connected anyway, and I personally prefer to keep the wrong value visible, because it may contain just one erroneous character - wouldn't like to force the user to retype it completely.

commandbutton's cancel property is that the btton's click code will be run if the cancel key is pressed. What is undocumented is that clicking the same command button with the mouse actually stuffs LASTKEY() with 27. This provides a little of the information you were trying to get with a commandbutton's when method.

Hey, didn't know this (though I've almost noticed it in the debugger, but I was following some other track and didn't pay much attention).

>The save method can loop through all bound controls and test the localvalid code also, using the failedvalidtext the same way before aborting the save and setting focus to the control.

Doing that too, sure.

>Resetting the control's changed property to .F. allows the user to tab out of the control after having seen the message once. Users do not always want to fill in information in the order that you have laid out, and I don't feel I should force them. If a user consciously (or accidentally) tabs out of a control that fails its validation test, don't worry, it will be rechecked before the record is saved.

You do have a point here... I'll probably do so for the time being (but then the user has to retype the whole .value); I'm thinking of a way to keep this value until the user reverts the field - which can be arranged in the local .keyPress on Escape: if .changed, revert the value and .changed=.f., else AbortRecord.click.

>This strategy follows the theory that users should be given 'help' along the way, but should only be forced to type something after they have requested that their data be saved. Best of both worlds, IMHO

I'll sign under that.