>>Hi Dave,
>>
>>Long time no speak. How are you?
>>
>>If I understand your question correctly why don't you put the SetFocus() in the LostFocus of the object you're trying to validate?
>>
>>Regards,
>>Gavin.
>>
>>>Setfocus() is not allowed to be called from a valid event of a textbox, editbox or spinner (there may be others, I don't know of). Not only that but setfocus() cannot be called if the valid event is anywhere in the call stack! I understand that doing a setocus within the same form or formset should not be allowed, but this is going too far!
>>>
>>>So, it's often the case in our system that a form is required to validate a users input. For example a form with an optionbuttons. If that form does a setfocus() anywhere then we get the usual error. So how on earth can I call a setfocus() (or do the programmatic equivalent) in a form that is separate to the form on which the valid() event is running??
>
>From my experience lostfocus() seems to be a poor place for data validation. The setfocus() is occurring in another form.
>Let's say I'm validating a date field. Imagine that we have something like
>procedure valid
>if ! between(this.value, date(), date()+7)
> dt= this.value
> do form ChooseDate with dt
>endif
>
>Imagine that ChooseDate form has a option group with a buttons labeled Mon,Tue..Sun (silly I know but I'm making this up as I go). So I might like to setfocus() to the radio button representing the most rational choice.
>But if the ChooseDate form does a setfocus() anywhere you get an error!
>My point is that what the heck does it matter if ChooseDate does a setfocus().

David,
My experience tells the reverse. IMHO lostfocus is a better place than a valid (if I need to validate there ever).
A simple skeleton works well for me :

* code doing validation checks,invoking another form etc
If !thisValid
nodefault && Needed even if this.Setfocus would be the code
endif

PS: With valid it matters any code in the chain does a setfocus because still the owner is the control.
Cetin