The L.A Fox Developer Newsletter

September 1999

Communications (Con’t from page 5)

strategy of surmounting these problems is especially critical if

you hope to create robust re-usable object classes.

To begin to examine these issues, look at the code below in

example 1. Create a program file containing this code, saving it

as MSGEXI . PRG and enter the following commands in the

command window:

SET PROCEDURE TO msgexl ADDITIVE

oTestObject = CREATEOBJECT(”Messager”)

? oTestObject.Name

This will return the name property of the object, ‘~Messager” that

is set in the class definition. If we use this name to try to call

one of the object’s methods (for example the SayHello()

method):

messager.sayhello()

This will result in an ‘Object “messager” not found’ error. Even

though the object’s Name Property is “Messager”, and the class

on which the object is based is “Messager”, this is useless in

directing a message to this object. What we need to use to

reference this object is the object-type variable that was used

when the object was instantiated, “oTestObject”. If we direct a

message to this object using its object variable name, we get

the expected (and desired) results, which is the MessageBox

saying “Hello”. This is shown in the following call:

oTestObject.SayHeIlo()

See code listing 1 for the source to MsgExI .PRG.

Listing 1. MsgExl.PRG.

“- PROGRAM MsgExl .PRG

Example 1

Demonstrates that being able to send a message

~- to an object depends on knowing the instance

~- variable of the object; that in the case of

-

a class derived from the Custom BaseClass, the

name property Is of no use in messaging

DEFINE CLASS Messager AS CUSTOM

name = “Messager”

FUNCTION SayHeIlo()

=MessageBox(”Hello! - This is “ +

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

ENDFUNC

ENDDEFLNE

(Note: An object’s name property is of importance in messaging

when the object is part of a composite object (also known as a

container object). When an object is contained within another

object, there Is no object-type variable used to reference the

object, and the object’s name property is then used to reference

the object’s properties and methods.)

Forms are an example of a common container object. In a form,

controls such as text boxes, command buttons, and so on are

referenced by their name property. The default name for the first

text box placed on a form is uTextin the second command

button placed on a form defaults to “Command2”, and the

developer may make a habit of renaming these objects to

something more meaningful such as “txtCustName” or

“cmdSave”. In the remainder of this article, I will use the term

object reference to refer to whichever name we can use to

reference a particular object—the instantiation variable name, in

the case of objects created using

<variable>=CREATEOBJECT() syntax, or the object’s Name

Property in the case of objects which are added to (and there-

fore, children of) other objects. Objects can be added to other

objects using one of the visual designers, an object’s

AddObject() method, or the ADD OBJECT command.

The most direct way of addressing a message to an object is to

do so by explicitly specifying the object’s object reference. Any

objects that are placed within a container object may reference

other objects in the container explicitly. In this case, using the

object reference is the preferred method; it’s simple and unam-

biguous.

However, designing classes to create reusable objects requires

that we carefully consider the object’s interface. By this I refer

not to the interface that the user is presented with in using an

application, but the interface that is presented to the developer

and other objects in the application. An object’s interface is its

exposed properties, methods, method arguments or param-

eters, and method return value types. These are the “hooks” by

which the object is used in the completed system. Implicit in

this “interface” is the requirement to not only know the names of

the properties and methods, the arguments the methods expect

and the values they return, but also to know the object reference

by which the object’s methods can be called.

When creating a reusable object class, keep in mind that you

may not know its object reference until the object is actually

included in an application, or possibly only at run-time. Consider

the following situations:

An object made up of a set of standard form navigation and

control command buttons needs to be able to function

properly (communicate with) any form on which it is used,

without regard to form’s object reference.

An object may need to communicate with a varying number

of other objects, all of which are instances of the same

class, and each would by necessity have a different object

reference.

An object may need to message different objects at differ-

ent times and under varying circumstances.

Clearly, if explicit object references were the only way available

to specify which object you are messaging, you’d have some

(Con’t, page 7)

Page 6