Dragan is right, if you have controls other than textboxes and editboxes (which was my example) such as comboboxes, optiongroups, command buttons etc., which can be manipulated by mouse, you'll need more. If you started with your own baseclass (vs the standard VFP baseclass) I'd build this behavior right into the ancestor classes.

As an example, in my framework I created a changed property (with assign event) normally fired by the programmaticChange/InteractiveChange event which enables/disables the appropriate buttons. The changed (property) is also used by other methods/events such as the form's QueryUnload event to warn the user if he's about to close the form w/o saving changes. Once in your framework, you can concentrate on the business rules at hand w/o worrying about remembering to set every control with the desired behavior. So, as I add controls to the form, they already have the proper and consistant behavior (e.g. enable/disable buttons, work w/queryUnload, etc...)

Dragan, thanks for clarifying my example!

---

>Not enough sense, unfortunately, because you may have things changed on your form with a mouse. It'd be something like thisform.RegisterTheChange in each control's .InteractiveChange method, and this custom method could set the property you want, or just simply enable the apply button. Also make sure apply button disables itself once it gets clicked - that's the regular Windows behavior and that's what your users may expect.