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”;

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 complexity, that is). What you might be wondering is, why would

(Con’t, page 7)

Page 4