The LA Fox Developer Newsletter

September 1999

Communications (Con’t from page 6)

major limitations in how you could design your systems. You’d

have to abide by strict object variable naming conventions in

order to avoid “breaking” all of your hard coded object variable

references. Also, in my first example above, how would a

command button class be able to communicate with any form,

regardless of the name of its object instance?

Be aware that these are not concerns of the object that we are

trying to reference (the “receiving” object) but the object that

needs to reference another object (the “sending” object). A

“receiving” object will respond to any other object or program

that properly calls one of its methods. This is not to say that the

“receiving” object can’t play a role in assisting the “sending”

object in solving this problem, as we’ll soon see.

The keyword THIS is used by an object to refer to itself, without

concern for it’s object reference. For example, an object can

call its own Print() method with the following line of code:

This.Print()

Likewise, If there is a parent-child relationship between two

objects, that is, one object is contained within another “compos-

ite” object, there is a keyword that the child object can use to

pass a message to the parent object without knowing the

parent’s object reference variable name. This keyword is

PARENT (no surprise). If the parent object has a Show()

method, a child object can send a message to the parent object

and have the parent object execute the coae in its Show()

method by executing the following command:

This.Parent.Show()

Be aware that the term “Parent’ is used in two different contexts

in Visual FoxPro, and this can cause some confusion. An

object instantiated from a user-defined class has a couple of

properties that provide information about the class used to

define it. One is the Class Property, which simply tells us what

class was used to define the object. Another is the

ParentClass Property. This tells us what other class the

object’s class may be subclassed from, and from which it

inherits properties and methods. The following class heirarchy

may make this clearer:

Form (BaseClass)

MyNewForm (defined AS Form)

MyNewestForm (defined AS MyNewForm)

In this example, an object derived from MyNewestForm will

belong to the class “MyNewestForm”, and its ParentClass will

be, “MyNewForm”. In OOP-speak, this is often referred to as

the object’s “Superclass”.

On the other hand, Visual FoxPro can also define a parent-child

relationship between two objects (not two classes), in which the

child object is “contained within”, and therefore dependent upon,

its “Parent” object—if the Parent Object is destroyed, so is the

Child Object. In this article, all reference to Parent-Child rela-

tionships are referring to “Parent” in the context of

containership, not inheritance.

Such a container relationship is demonstrated by the objects

defined in Listing 2, “MessageParent” and “MessageChild”. Note

that we could instantiate MessageChild at the command

window or in a program by executing this line of code:

oTestObject = CREATEOBJEcT(”Messagechlld”)

In this case “oTestObject” would be used to reference the

object. However in the example, MessageChild is instantiated

using the AddObject() method of the Custom Base Class, and

its name property is set as “Childi”. This instantiates an object

derived from MessageChild as an object “contained” within the

object oParent. The following commands issued in the com-

mand window demonstrates the functioning of these two

classes:

SET PROCEDURE TO MsgEx2 ADDITIVE

oParent=CREATEOBJECT(”MessageParent”

oParent.Childl .SendMessage()

See Code Listing 2 for the source to MsgEx2.PRG. Notice that

when MessageParent is instantiated as oParent, its lnit()

method is automatically called. Init() adds a child object called

Childi, of class MessageChild to oParent. The Childi object

(derived from MessageChild) has only a single method,

Send Message(), which in turn simply calls its parent object’s

SayHello() method using both the THIS and PARENT keywords.

So when oParent.Chiidi .SendMessage() is executed in the

above sample code, oParent’s Say Hello() method is fired

because the Child 1 object executes This. Parent.SayHello~.

Listing 2. MsgEx2.PRG.

*

PROGRAM MsgEx2.PRG

*

Example 2

*

Demonstrates how a child object can reference

a method of the parent object without regard

to the name of the parent object or its

*_ instance variable

DEFINE CLASS MessageParent AS custom

ADD OBJECT Childi AS MessageChild

name = “Parent_Object”

FUNCTION SayHello

MessageBox(”HeIIo! - This is “

This.Name,O,”Messaging Example 2”)

ENDFUNC

ENDOEF1NE

DEFINE CLASS Messagechild AS custom

FUNCTION SendMessage

This.Parent.SayHelIo()

ENDFUNC

ENDDEFINE

(Note that there is nothing in the class definition for MessageChild

that tells it how its parent object is instantiated, nor what the

(Con’t, page 8)

Page 7