The LA Fox Developer Newsletter

February

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. Polymor-

phism 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.

oEXAMPLE=CREATEOBJECT("CHILD")

oExample.Show()

READ EVENTS

DEFINE CLASS grandparent AS FORM

PROCEDURE DBLCLICKØ

WAIT WINDOW “Grandparent’s Double Click”;

TIMEOUT 1

CLEAR EVENTS

ENDPROC

ENDOEFINE

DEFINE CLASS parent AS grandparent

PROCEDURE DBLCLICKØ

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 I

CLEAR EVENTS

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-dnven”) 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 system. 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 hierar—

chy 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

(Con ‘t, page 5)

Page 4