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.
So we've taken to KEYBOARDing CHR(9) s to workaround the setfocus issue. But this is a horrible kluge.


>Valid() can return a numeric value. For instance, if it returns 2, the cursor will advance 2 objects.
>
>However, I want to present a completely differnet approach, which you might consider. I have used it at Bata/Bolivia, and the users didn't complain of this particular aspect (this is not a sure sign of quality, I know!).
>
>Instead of validating each TextBox, etc., I validate the entire record when the user saves (Form.Valid() method, provided by the framework). This leaves the user the flexibility of entering data in any order, but invalid data will not be saved.
>
>Once the user tries to save, he will see a MessageBox, stating that the record can't be saved, because (for example):
>
>

>FieldX needs at least 5 characters.
>FieldY can't be empty.
>FieldZ must be positive.
>...
>

>
>BTW, this validation is done through rules (and messages) stored in a table.
>
>HTH,
>
>Hilmar.
>
>>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??