Yes. I agree with you, Dragan. I formerly believed that very light validation (does the customer # exist, did the user attempt to leave the field blank, etc.) should happen at the object valid level. However, assuming Jim Booth's "normal" suggestion works, perhaps we can use more heavier validation in the object itself, then do the save-time validation to be sure the user didn't skip anything, or if the user edited instead of added a record, to be sure that the data in the objects still works together. I use mIsOK=Thisform.MyObject.Valid() quite a bit, then if mIsOK = .F., I fire a messagebox and don't allow the record to be saved.

JR

>>>IMHO, there are no normal ways to do this, and this is one more reason to
>>move validation into one place (e.g. cmdSave.click). However, you can make
>>some trick using cmdExit.MouseMove event.
>>
>>The reason for this Bela, is that the validation will be fired BEFORE the
>>click. It is not the click of the button that fires the validation. It's
>>the object's losing focus that fires the validation. Therefore, it's
>>impossible to know at that point, the point of the focus leaving that
>>field, where it's going next.
>>
>>I'd agree with Edward on this. A CheckSave method at the form level is
>>better.
>>
>>JR
>
>We seem to have a long and recurring dispute on in-field validation vs
>save-time validation. Let me summarize a little:
>
>in-field validation:
> + reacts directly to user input, no delay
> + some further fields may be dependent on the validity of a field, so
>it better be valid before we get to these fields
> + validation code is in the object, not separate - object can be reused
>in another form
> - if the field is skipped by clicking to a later field, validation
>never fires
> - if user escapes from invalid entry, validation won't let him out;
>needs some additional coding to fix
>
>save-time validation:
> + all the validation code is in one place
> + it can be called from anywhere in the form all at once
> + fires before saving and checks everything, no skipped fields
> - needs additional coding to set focus back to the erroneous value
> - needs additional coding if a control is copied to another form
>
>I think I've got, if not a best-of-both solution, but an idea for it.
>The SaveCheck method should call all validations in turn, i.e. for all
>the objects which may have validation, and AND the results. If any of
>them fails, SetFocus to the object. This may be done in
>SaveButton.click; the validable objects should have some property to be
>recognized as validable (my private candidate is .say property, which
>I have in all my controls classes; it was originally intended for
>situations when all the controls were disabled, to be .t. for those
>which should be re-enabled later). So any object could be validated
>in-field, and/or from SaveCheck method.
>
>Comments? Volunteers?