>>THIS QUESTION IS NOT AIMED AT FIELD VALIDATION, but to when to perform recalculations. In Fox 2.x I would create an old value, have it pick up the value in the input field in the when clause, and then compare it to the actual value in the valid clause. In VFP I am not quite sure when to do this. If I use the above methodology, should I move picking up the old value into the gotfocus and then check it against the new value in the lostfocus? [It is vitally important that whenever a value is changed a recalculation occur, but since recalculation is time consuming it should occur only when a value changes.] I originally thought that in VFP, I would be able to just compare the .value against whatever it is bound to in the valid clause but that does not seem to work consistently. By the way, when does the underlying value get changed? Is there an ironclad rule to this? This is such a seemingly simple thing but it is turning into something for me that is akin to getting foxpro to quit when
>it
>>does not want to.
>
>It depends on using buffering or not. If you use buffering then OLDVAL() will return the value, if not and textbox is unbound then field value is still here until you save a record.
>Also, you have InteractiveChange event to track user's activity.

From what I understand of Calvin's question, InteractiveChange would fire too often (Calvin, every time user presses a key the event fires).

I think, if you're not talking about validating the field or deciding whether to allow the user into it, that it makes sense (as you said) to move the code to the GotFocus and LostFocus events. It will still work in the When and Valid events, but I try to remember to move code from When/Valid to Got-/Lost-Focus if the code isn't actually Whenning or Validating :). For clarity.

The other question is how to tell if it's changed. As Ed said, it depends on whether (and how) you're buffering. Read up on buffering, OLDVAL, and CURVAL. It's definitely important to learn about this.

However, that being said, your old method of setting a var on entry and checking it on exit will still work, assuming the variable is properly scoped.

HTH,