Tks for the explanation.

>Allan,
>It's my fingers not me :) They want to be free while coding a validation and sometimes want to code calling other forms, messagebox etc.
>Letting valid to do it was a bug up till VFP7 and corrected in VFP7. Another unanticipated side effect occured. Now in VFP7 if valid calls another form and returns a value no matter the return value is you should expect wird behaviours like losing where you're (see details more on this on a message in the last 1-2 days. Search for grid, valid and lostfocus).
>OTOH lostfocus is a nice place to code validation. If it fails I could mimic valid's return .f. :
>
>*...
>if !Validated
> nodefault
> this.Setfocus
>else
> * return .t. situation
> * extra code if desired
>endif
>
>Doing like this I can also Setfocus from a valid (which is no more a Valid but Lostfocus event:) IOW freedom to code.
>
>Interactivechange lValid is same as valid setting lValid. ie: if input wouldn't be a number less than 100 :
>
>*InteractiveChange
>thisformset.lHangingValidation = (this.Value < 100)
>*Valid
>thisformset.lHangingValidation = (this.Value < 100)
>return !thisformset.lHangingValidation
>
>Honestly I forgot why I needed to support it with InterActiveChange then. But I simply thought if I did it there was something hit me and it was the fix :)
>Cetin
>
>>Cetin,
>>
>>If I may ask two more short questions?
>>Why don't use the valid clause
>>What would the code for a typical interactivechange contain in terms of what happens when the data is invalid?
>>