>Barbara,
-- snip --
>I have button classes that never get instance code and they don't have do case in them at all. They call method of the fomr to get the services. If you think about a command button's purpose in life is to provide a way for the user to communicate with the system. If that is true then command buttons have no business doing anything but passing a message on to some other object that manages the requested service. For me, I see forms as the object that is respobsible for record movement, editing control, saving, reverting, etc.. My form calss has a DoEdit method, a GoNext method, etc..

If this is ALL the form does, then you are absolutely correct, and the same button-classes on the same form-class will work everywhere. However, I often have forms that require a data export or a series of calculations for some specialized purpose. These buttons have a line of code calling a form-specific method, and there is no reason why they should be part of any class other than my button-base.

-- more snips --

>I see this issue as having an apple, the OO way says cut the apple and get the seeds and plant them and wait. The procedural way says eat the apple. If I eat the apple I get immediate gratification. If I plant the apple I a lifetime of gratification but I have to wait a while before it starts.

Perhaps we're arguing apples and oranges. I'm not suggesting procedural code is the way to use VFP (Heaven forbid), just that instance code is sometimes appropriate, and needn't be 'classed' unless it's being used more than once.

A form class is just that - a class, not the end of the production cycle. If we only needed 'standard' forms there would be no reason for form-specific properties and methods.

Barbara