>I routinely build a .oldvalue property into any class that can hold a value. That way I always have an absolute record of any value change. Just assign .oldvalue = .value in the GotFocus() event. Then you can test from any position in the form for .oldvalue = .value and take appropriate action.

I have the .old property in all my classes already, but for a different purpose - it holds a value from the previous record. It's probably legacy (I've had that in FPD2.x and Fp1.x and mFoxPlus...) but my users are used to it; on keypress of F4 this value should get copied into the current control's .value, and on F3 the automatic copying for the current control should be turned on or off. I say "should", because I can't figure out why doesn't the form's keypress react to these keys (form.keypreview=.t., of course) as it does on other keys. Probably some legacy properties on Set Function or such. Well, that's another issue anyway, but having this led me to a completely different path - so your idea is a real surprise for me (banging my head against keyboard).

Though, later when I thought about it, previous value is not of much use for me, because I can easily construct a situation where this value is wrong (legacy data that need to be updated, for one). This doesn't diminish the value of your idea - I'll surely use it somewhere else. I've managed to get my .IsChanged property working properly. Now I have the validation fire the way I wanted it (until I discover a bug in this :) - it validates if user fiddles with the control, and it doesn't if user exits from an untouched control, and then it validates once more when the user saves. Knock on wood.

Hey, this OldValue could be used for in-control reverting. Press Ctrl+Z to restore old value :). Why not.

>This is a holdover from old Clipper code. I'm certain there are modern, OOPS ways of doing the same thing that are much more elegant.

Yes, stuff the thing into control's class and forget about it :)

Thanks, this was a real lightbulb.