That is indeed an interesting approach. However, I have two complaints about your code. One, after "case Ok = .T." and "case Ok = .F.", none of the remaining code will execute (unless it is assumed that Ok can have a null value). Two, the TabIndex may have missing numbers, if an object is deleted. Since the solution is otherwise quite efficient, I would simply the developer makes sure to set the TabOrder interactively after deleting objects.

>To "Setfocus" to another control using the return value from the valid event is made more acceptable using the this control / that control offset technique like this:
>

>textbox::valid
>
>do case
>  Case Ok = .t.
>    RetVal = 1
>  Case Ok = .f.
>    RetVal = 0
>  case goto_textname
>    retval = this.tabindex - this.parent.textname.tabindex
>  case goto_texttype
>    retval = this.tabindex - this.parent.texttype.tabindex
>  case goto_ComboYear
>    retval = this.tabindex - this.parent.ComboYear.tabindex
>endcase
>return retval
>

>
>Glenn
>
>>>I agree with your approach of doing a form level valid completely. And we are moving to doing more of this.
>>>However our large existing app has around 400 forms - so it would be quite a task at this stage.
>>
>>Yes, that looks like a lot of work.
>>
>>>So we've taken to KEYBOARDing CHR(9) s to workaround the setfocus issue. But this is a horrible kluge.
>>
>>That should be more or less equivalent to valid (number). Also a kludge: in both cases you have to count objects, and adjust if you insert additional objects.
>>
>>BTW, with the KEYBOARD command, I think you can also use "{TAB}" instead of chr(9). This might make it more readable.
>>
>>As a workaround, if you can't SetFocus() within the Valid() event, you might postpone it with a Timer (with a brief interval). But I don't know whether this works; perhaps the Valid() will then fire again.