Hi, Doru.

We use another approach, but I think that this solution would imply a lot of rewrite, too.

We NEVER return .F. from a valid. If the value is absolutely incorrect (an inexistent code, for example), a short message (wait window nowait) is displayed with a beep, and the value is cleared.

All of the final record validation is made in a custom property of our forms, that is called before allow the user to edit or save the data.

Our users are very comfortable with this approach, because it don't stop them even from jump from control to control. And of course, doesn't block them for Cancel, neither.

Just what we use...


>So, again, how do you force valid to return .t. when the user is cancelling at the class level? I have the solution that involves DoDefault() calls in controls valid - maybe it is not that bad, in fact there might be only a few cases were I need it (when valid code needs to return .f. or 0). On the other hand, the code I put at the class level will execute for all controls that have no valid code on the forms - another little overhead... Maybe a clearer mind will say that this is the best you can do?