In addition to the othe comments, you can use WHEN to prevent focus. One post suggested lostfocus instead of valid. Valids behavior is downstream restrictive. Also, if you have a clear button, and the cursor is in a control with a valid restriction, when you click the clear button, the valid code will fire.

One method:

PROCEDURE MyText2.When
RETURN !EMPTY(MyForm.MyText1.Value)

or, if a complex valdidation is required, you could attach a flag property to the form "lOkayToAllowFocus" and set the validation in MyText1's LostFocus method:

PROCEDURE MyText1.LostFocus
IF(SEEK(this.value,"MyDBF","MyDBFTag")
   MyForm.lOkayToAllowFocus=.t.
ELSE
   MyForm.lOkayToAllowFocus=.f.
ENDIF
ENDPROC

PROCEDURE MyText2.When
RETURN MyForm.lOkayToAllowFocus
ENDPROC

>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??