That's an interesting problem and I'd like to hear other opinions here as well. It may be a better idea, especially in WEB based application, where changes are done through web forms and Java scripts handle problems without requiring a trip to the server.

Of course, your idea requires special form and user control classes, but I'm sure you have them developed already in your framework.

In The MereMortals framework for VFP the data changes are detected on the database level, that creates an extra complexity.

>The Save button is initially disabled. If changes are made, the Save button is enabled. This test definately belongs in the UI because it enables a button.
>
>The flag is actually on a facade object to the business object and is checked if the user tries to navigate off the changed record or close the form without saving. If that happens, a dialog is thrown up informing the user that changes were made and asking them to save, continue and not save, or not continue.
>
>I don't ever have to worry about detecting changes using GETFLDSTATE() or GETNEXTMODIFIED(). The flag handles that.
>
>>Why are you tieing data changes detection to the interface? AFAIK they should not know about each other. Though of course this approach can be used.