>>Like Garrett, I think "2" is the correct solution. You can put code into your
>>base class, then overwrite it easily if you need to. And sometimes you'll want
>>to Save from other methods besides the 'SAVE' button.
>
>Didn't say _that_. :-) Just because I do it doesn't mean I think it's the right way: I suspect 3 is the correct solution, but as the original poster mentioned, my comfort level is low.

Garrett,

None of them and all of them are correct solutions. The decision is one of design. In the design you must identify the object that is responsible for the data. You may decide that in your applications it will be the form, or you may decide that it will be the buttons, or even a thrid object that is neither. Makes no difference in terms of right and wrong. What is wrong is making a design and then not following it. Using the fomr is fine, using the button is fine, and using another data object is fine, as long as you do it the same way every time.

Any one of the three can be defined as a class and used to create objects. The argument of rebuilding a form doesn't hold water, if the data object can be a class and be dropped on the fomr, why can't the fomr be a class and use the class to replace the bad form?

My framework uses an frmData class for all data aware forms. All of teh data handling code is written in the class. The buttons, toolbars, and menus all call the form's methods for data services.

That's true except for the N-Tier framework, that one uses an ActiveX Server to handle data.