BaseClass, Class, ParentClass

These properties give you the pedigree of an object. They tell what class it’s based on (Class), what class that class was derived from (ParentClass) and which of Visual FoxPro’s base classes this whole inheritance chain derives from (BaseClass). Don’t confuse ParentClass with Parent, which tells you what object contains the current object.

Usage

cClass = oObject.BaseClass
cClass = oObject.Class
cClass = oObject.ParentClass

These properties trace the class hierarchy, the family tree where one class derives behavior from another. They don’t trace the object hierarchy, in which one object contains another.

Every class created in Visual FoxPro must originate from one of the built-in base classes. (See “Base Clef” in “OOP Is Not an Accident” for a list.) The BaseClass property contains the name of the Visual FoxPro base class that is the ultimate ancestor of this branch of the family tree.

Every object is based on a particular class, which is used as a template to create it. This is the class named in the CREATEOBJECT() function or in the ADD OBJECT clause of DEFINE CLASS or in the AddObject method used to add this object to another. The Class property tells us which one it is.

Finally, the class on which an object is based may be based on another class. That is, the class may be a subclass of another. This is the ParentClass of the object—the class from which its Class was derived. Microsoft introduced a lot of confusion here by calling this property “parentclass”—many OOP languages refer to it as “superclass” instead. The “superclass” terminology is somewhat less confusing because it matches “subclass.” Nonetheless, if you visualize the family tree, you can see that the ParentClass of a class is the class one level up.

When an object is based directly on one of the FoxPro base classes, ParentClass is empty. That’s because there’s nothing one level up the class hierarchy.

You can’t change any of these properties. Once you create an object, its class derivation is fixed. This is one reason we (along with the other experts) recommend you create subclasses of all the FoxPro base classes and subclass all your own classes from those. The Class Browser’s Redefine button does let you change the class an object is based on, but it can’t fix up all the things such a change affects.

Occasionally, you want to know more of the hierarchy than these properties give you. The AClass() function is handy in that case.

Example

oTest = CREATEOBJECT('Form')
? oTest.Class           && returns "Form"
? oTest.ParentClass     && returns ""
? oTest.BaseClass       && returns "Form"

* put the following in a program and run it
oParent = CREATEOBJECT("testParent")
oParent.ShowYourRoots()

oChild = CREATEOBJECT("testChild")
oChild.ShowYourRoots()

oSibling = CREATEOBJECT("testSibling")
oSibling.ShowYourRoots()

oGrandChild = CREATEOBJECT("testGrandchild")
oGrandChild.ShowYourRoots()

DEFINE CLASS testParent AS custom

   caption="My first class"

PROCEDURE ShowYourRoots
   WAIT WINDOW "Object = "+This.Name+CHR(13)+ ;
            "Class = "+This.Class+CHR(13)+ ;
            "ParentClass = "+This.ParentClass+CHR(13)+ ;
            "BaseClass = "+This.BaseClass
ENDPROC

ENDDEFINE

DEFINE CLASS testChild AS testParent
   caption="My second class"
ENDDEFINE

DEFINE CLASS testSibling AS testParent
   caption="Sibling rivalry"
ENDDEFINE

DEFINE CLASS testGrandchild AS testChild
   caption="My last class"
ENDDEFINE

Each object in the example shows for Class the name of the class you passed to CREATEOBJECT(). For ParentClass, it’s the class named in the AS clause of the DEFINE CLASS command. Note that oChild and oSibling have the same ParentClass because the classes they’re based on (testChild and testSibling, respectively) are both derived from testParent. Finally, the BaseClass for all of them is Custom because the first class we create in this hierarchy (testParent) is based on Custom.

See Also

AClass(), CreateObject(), Define Class, Parent