I think that it is not common to have business logic in the ExecClickAction of the OK button. When the OK Button is clicked, it is clicked independently of the form state (invalid fields). The role of the OK Button is to trigger a doSave() on the form nothing more. (It is possible to call doSave() from another button or as reaction of a specific event)

After that the FormHanler will handle the form life-cycle. You can add additional checks to the build in checks (like the message box you mentioned):
* ExecCheckField
* ExecValidate
* ExecStore

ExecStore is only called if CheckField (build in and custom) and ExecValidate (build in and custom) are successful. I recommend you to move you logic there.

If you have two form hanlders (one for NEW and one for MODIFY) and your business logic is the same you can put it in a function that you call in both cases.

In typical application this does not matter, because the whole form is exported in the formData and sent to the server.

I think each field can provide information if its value has changed: with IFormField#isSaveNeeded().
I recommend you to make some deep tests, because I am not sure how reliable the information is (for example if the user make some inputs in the field and cancel them).

Hi Jeremie,
I moved my business logic in ExecStore of the handlers "NewHandler" and "ModifyHandler", because is the same.
When I click on OK Button, these methods are not called. What I forgot or wrong?

execStore of the FormHandler is called if there is some modification in the form.

Scout Forms check if there was a modification in any field (corresponding to the method: getXxxxField().isSaveNeeded() ) If so the form is considered as modified. In such a case execStore of the form handler is called.
You can "check" the state of your form: if you click the cancel button and one of the fields has been modified, a message box will appear.

You can "touch" the form (mark the form as modified) by calling touch() in the execPostLoad method of the form handler.