>>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?
>
>An "abstract" class is any class that is not meant to be used directly, only subclassed. Supposedly, if you don't subclass it, it would be incomplete.
>
>Languages like Pascal allow you to enforce this in the class definition: if a class is defined as "abstract", it can't be used directly.
>
>Hilmar.

Hi Hilmar,

I understand what an "abstract" class is, I just don't understand it's value. If you tell me that VFP's BaseClasses are the "abstract" class and VFP's _base.vcx is the "concrete" clase then I get it completely.

But somewhere else on this thread, someone said that the closest thing to "abstract" in VFP is _base.vcx (but it was loaded with too much functionality). He seemed to be saying that if I create "abstract" myBase.vcx from VFP's BaseClasses, that I should not use myBase.vcx classes to create objects. I should then create "concrete" mySubBase.vcx classes from myBase.vcx to use for objects. I'm trying to find the value of that middle layer of classes.