I agree with this approach instead of using LostFocus or Valid. Another big advantage for me is being able to "read through" my error trapping in one location to be sure I haven't overlooked a case. That is a pain with individual error checking...

Instead of a simple return, though (which will take you back to the OK/Save button) I set focus back to the error-causing object.


>>Got a date range, and if the Beginning Date is empty, but the user puts a something in the End Date, I need to display an error message and put the focus back in the Beginning date.
>>
>>So, someone please remind me how to do that?
>>
>>Thanks
>
>SetFocus() method might work. But personally, I prefer a different approach: Postpone all validation. Only when the data is saved (or when the user presses an "OK" button to fire some other action, such as printing a report), should you run some code that does all the required checks. Just tell the user what is missing, and let the user complete the missing information, something like this:
>
>

>do case
>case empty(ldDate1)
>  ErrorMessage('You need a "from" date.')
>  return
>case empty(ldDate2)
>  ErrorMessage('You need a "to" date.')
>  return
>case ldDate1 > ldDate2
>  ErrorMessage("The second date must be equal to, or after, the first date.")
>  return
>endcase
>
>* Processing continues here
>

>
>I am assuming a UDF called ErrorMessage().
>
>The advantages of this approach are several. For one, the user can input data in any order. Two, programming the entire validation is fairly straightforward, and you can easily introduce conditions that span more than one field (such as the last CASE in my example).