If it was the valid event, I'd have to compare old to new. So, you need the overhead of storing the old, and checking it.

As for retyping, I looked at how lots of other applications work. The VFP editor simply detects changes. If one is made, the Save button is enabled. It doesn't care if it was changed back.

In Word, the Save button is always enabled, but if you quit without saving, it will warn you. It too doesn't care if the change was typed over.

Additionally, to check all the possibilities, the undo mechanism would get extremely complicated. What if the user makes a change, then tabs off the control, then back and then puts the data back? What if you have a parent-child form and you add several child records, then delete all the ones you just added? There are endless possbilities. I decided to keep it simple. If there's a change, no matter what it was, always handle it the same way.


>Since we're discussing "best practices", I'm curious what your reasons are for using the InterActiveChange event for setting the data-is-changed flag, instead of waiting until the Valid event & doing something like compare the OldValue vs. NewValue. To me there would be lots of repetitive calls to the InterActiveChange event, instead of a single call to the Valid event. Also, if the user accidentally made a change & retyped over it, using the InterActiveChange would regard that as changed, whereas using the Valid approach would not set such a flag.
>
>Again, your thoughts appreciated.
>
>Randy W.