>>Barbara,
>-- snip --
>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 --
>
>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,

Ok, we are rapidly moving from class versus instance programming into OO design issues. In ture OO the form would not do the importing or exporting of data, there would be another behavior object that did that. The OO desing of the behavior objects would provide a commmon developer's interface so that the buttons and forms could be generic while the behavior object was changed. This design, actually a bridge pattern, makes it even possible for the form to change its personality while it is running. It just simply instantiates a different behavior object and suddenly the buttons do something different.

I am not trying to be argumentative here, I am just really enjoying the give and take and I hope this thread is valuable to oehter as a result of you and I exchanging ideas.

One thing that is really important if new ideas are going to make things better, is to have a healthy scepticism about them. Playing deveils advocate, you are giving these ideas that needed scepticism.