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

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 therefore, 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 unambiguous.

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 parameters, 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 different 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