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 “composite” 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 command 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.

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