>>I'm just trying to find a way to keep everything encapsulated in one location. The >form really has nothing to do with what I need to have happen when I click the >button. I would like to keep all the code inside the button, but I don't like >creating a class for a single use. I'm hoping someone has found a different >solution.
>
>>In theory, I would like to keep it possible (even though I would never do it) to >copy the button into the clipboard and paste it into another form. Just the way I >prefer to program
>
>The desire to add properties and methods to the VFP base classes is a good reason not to use them directly, but instead create a complete set of subclasses that give you the complete functionality of the base classes. These are generally thought of as "abstract" classes and are not meant to be instantiated into objects. A second set of identical "concrete" classes is derived from this abstract set and can be used just like the VFP base classes. This second set can also be subclassed as needed to meet specific needs for extended functionality, like the button method you would like to implement.
>
>I know this is pretty far afield from your original question (and only a gloss of the subject), but you cannot create the button method without subclassing. Markus Egger's book "Advanced Object-Oriented Development with VFP 6" is an excellent discussion of the subject.
>
>John

Hi John,
Am I reading this right?
You're saying to have "abstract" classes that are not meant to be instantiated into objects, but then have a set of "concrete" classes to use in objects. What's the point of the "abstract" classes? Are these "abstract" classes the same thing as VFP's "foundation classes"?

I'm currently using a set of classes that are derived from VFP's foundation classes. I leave the foundation classes alone (so that future updates can replace them), and use my classes in objects. Is that what you're talking about?