>Seriously, it seems logical to me that the more dodefault() calls you have to make, the more likely your class design is questionable. I mean, if something is the default, everything else should be an exception.
>

True, if you have a lot of DODEFAULTs all over the place, but that doesn't mean they're inheritently bad.

>
>>FWIW, if valid returns 0 or .F., I think displaying a message that the data isn't valid and can't be saved is perfectly acceptable. If you want, you could offer to discard changes instead, and call the same method as the cancel button.
>
>True, but I thought it will duplicate the Cancel button functionality on the form.
>
>May I ask, how do you handle this, do you have a standard approach?
>

My apps save data automatically. I tried adding options to save or cancel, and when it came time to do rewrites I asked the users if they liked having that. They said they preferred the saves to happen automatically. In fact, in one app, they specifically requested that I do automatic saves periodically because they would stay on a record for a while, but wanted others to see the changes.