>I'd like to play devil's advocate, here, Jim. Not that you're entirely wrong, but I think you've left out something.
>
>I can understand "Class only programming" in theory, but do we really want a button class with 10 subclasses, each of which have a giant case statement in the Click() method? Sure, we need a CANCEL button class, and SAVE and UNDO button classes, but what about all those OTHER buttons? Buttons which call a form method specific to that form? Buttons which load another form?
>
>The ability to overwrite a class method on a form is at least as important in OOP programming as the class/subclass basis.
>
>JMHO
>Barbara

Barabra,

Ok I'll play. I didn't say that the OO purist approach is necessarily the pragmatic approach. In pure OO, like smalltalk, there is no way to do things other than using classes. Smalltalk has no concept of instance programming.

VFP, OTOH, is a hybrid language with both procedural and OO aspects to it. You can do pure OO with VFP if you want to. Or you can mix and match OO with procedural approaches.

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..

In the form class these methods are coded generically to handle whatever they find in the DE for the form. An example is the article I wrote for FoxTalk about a year ago, Classy Way To Save Changes. In the article some of the code from my data aware form class was described in detail. The code saves the changes to data. It doesn't care what tables are open, which ones are buffered, it even handles views. This is done by not thinking in terms of instance programming, but instead figuring out how to write reusable code that doesn't need any instance programming.

A very large application is built with that form class and no programmer has ever had to write code to save changes. Of course the form class does more than that, it handles reverting, record movement, enabling and disabling toolbar buttons, etc..

IOW, pure OO is achievable and it does have benefits once achieved. But getting there requires a major change in mind set. A big part of the difficulty in learning OO is to argue with the tenents from a procedural background. That is a no win situation for the eprson trying to learn.

When I teach this stuff I tell the students that they should take all they know about programming and set it aside. Then study OO. When you feel you have a handle on OO, pick all you knew before and it will apply. The problem is when we start to filter the OO information through procedural colored glasses. Suddenly we can't see the true benefits of using an OO approach.

Now, I'm not saying I never do instance coding, but when I think I should I step back and think very hard for a better way to get what I want.

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.