The LA Fox Developer Newsletter

April 1998

Polymorphism

by Jim Haentzschel

Welcome to object oriented programming! As soon as you get

here, the first thing people tell you is: “throw away everything

you know about programming and start over.” Great! Actually,

it’s not that bad. You’ll still need to know all those cool built-in

FoxPro functions. However, you’ll also need to understand all

these new object-oriented terms and, more importantly, how to

apply them to your applications.

In this article, I’m going to discuss one of the most confusing

sounding topics, but ironically one of the easiest topics to

understand: Polymorphism. Polymorphism is simply the ability

of different objects in your Visual FoxPro class hierarchy (with

the same method name) to have their own unique behavior. As

you can see, that’s a mouthful. Okay, so what does this

mean? Let’s look at some code. Below, I’m going to set up a

simple class hierarchy like one you have in your own family

tree.

oExampIeCREATEOBJECT(”CHILD”)

oExample.Show()

READ EVENTS

DEFINE CLASS grandparent AS FORM

PROCEDURE DBLCLICKO

WAIT WINDOW “Grandparent’s Double Click’

TIMEOUT 1

CLEAR EVFNTS

ENDPROC

ENDDEFINE

DEFINE CLASS parent AS grandparent

PROCEDURE DBLCLICKO

WAIT WINDOW “Parent’s Double Click”;

TIMEOUT I

-

CLEAR EVENTS

ENDPROC

ENDDEFINE

DEFINE CLASS child as PARENT

PROCEDURE DBLCLICK()

WAIT WINDOW “Child’s Double Click” TIMEOUT 1

CLEAR EVENTS

ENDDERNE

In this code we have a simple class hierarchy. Note that the top

level in our class hierarchy is grandparent. Grandparent’s

descendent class is parent, followed by child. Each class has

its own DBLCLICKO method code. (You could create the code

above by using the Visual Class designer, but looking at raw

code is more helpful here. I always use the visual tools in

practice, but when you’re trying to understand how something

works, there’s no substitute for hacking small pieces of code

like the code above!)

So far we only have three classes defined, albeit a class

hierarchy (that is, the classes descend from each other). To

actually see anything on the screen, we need to create an

object. Remember .that an object is the living thing we use in our

applications (not the class itself, which is just the blueprint).

To create an object, we use VFP’s CREATEOBJECT() function.

You’ll see at the top of the program three lines:

oExample=CREATEOBJECT(”CHILD”)

oExample.Show()

READ EVENTS

The first line creates an object based on the child class. The

second line shows the object on the screen. Finally, the third

line READ EVENTS tells VFP to activate the objects you’ve

created. You issue a READ EVENTS command when you’re

done setting up your applications menu, objects, and any other

things unique to your application. If you forget to include the

corresponding CLEAR EVENTS at the end of your program,

VFP will reward you with a hung computer. Therefore, you must

eventually CLEAR EVENTS in your application to return control

to VFP. You will probably call CLEAR EVENTS when you exit

the application. Before issuing the CLEAR EVENTS command,

you would want to query any open forms to make sure it’s

okay to quit. If you CLEAR EVENTS and there are open forms

in editing sessions, you’ll get an error,

Messages

Windows is a message-based (“event-driven”) OS. Everything

you do in Windows sends a message to Windows. These

messages include things like MOUSEMOVE, DOUBLECLICK,

KEYPRESS, and other events. Now, VFP, unlike previous

versions of FoxPro, (finally) uses the native Windows message

in our example above you can send a message to

the form by double clicking on it. You’ll see in the form class for

child we have method code (remember that “click” is the

event, but the code that responds to the event is the method).

Notice too, that the other classes in our hierarchy also have

double click methods.

Here’s polymorphism in action! If you run this code and double

click on the form, you’ll see the WAIT WINDOW for the child,

even though child is derived from two higher classes! That’s

polymorphism: the ability of the child class to correctly execute

the code for its double click event even though other classes in

the hierarchy also have double click code.

Let’s look at this concept another way. You are your parents’

child. However, both you and your parents share common

“reactions” to events. For example, if you got hit on the head

with a stick-the event-you would have a reaction. If one of your

parents got hit on the head with a stick, they would also have a

reaction (though they wouldn’t like it either).

Note that this example breaks down a little, since VFP doesn’t

support multiple inheritance. That is, you are the descendent

of both your parents-you inherit from both of them. Other

languages, notably C++, do support multiple inheritance.

However, there is some debate about how much multiple

inheritance adds to most applications (other than much com-

plexity, that is). What you might be wondering is, why would

(Con’t, page 7)

Page 4