>I don't follow.  If cWindow class is a subclass of cObject (the base 
>class), and as such inherits cObject's methods and properties, and you 
>pass an object of type cObject to a function, why would that function 
>need or want to use cWindow's Draw method rather than cObjects?

David,

As I said this is a concept that is best demonstrated by some sample 
code. Since I seem to have caused a bit of an uproar I will now explain 
with some C++. This sample is fairly short and abstract but easy to 
follow and demonstrates the concept. I am also paraphrasing from a  good 
book called "Thinking in C++" by Bruce Eckel.

Everyone on the list have no fear it's fairly simple once you get it. 
There are many books on object oriented methodology ... check your 
favorite local book store! Once the light switch flips on the concepts 
you will wonder how you ever worked procedurally. I can't promise it 
won't be painless but it's one of those situations that you makes you 
feel good when you get it!

// Here is the problem situation

#include <iostream.h>
enum note { middleC, Csharp, Cflat };

class instrument {
    public:
    void play(note) const {
        cout << "instrument::play" << endl;
    }
};

// Wind Objects are instruments because they have the same interface

class wind : public instrument {
    public:
    void play(note) const {
       cout << "wind::play" << endl;
    }
}

// Here's the explicit problem ... a function which takes a pointer to a 
base class
// even though each inherited class has it's own over riden method

void tune( instrument& i ) {
    i.play( middleC );
}

main() {
    wind flute; // new object of type wind ... just an instance of our 
class
    tune( flute ); // resolves to the base instrument class not the wind 
class
}

Running the above program gives us the output ... instrument::play ... 
not the desired output because the object is of type wind ... but 
compiler early binding causes the tune function to resolve to the base 
class instrument because that is what it knows about that function from 
it's parameter list.

// Here is the simple solution

#include <iostream.h>
enum note { middleC, Csharp, Cflat };

class instrument {
    public:
    // ******** Note the addition of the keyword virtual *********
    virtual void play(note) const {
        cout << "instrument::play" << endl;
    }
};

// Wind Objects are instruments because they have the same interface

class wind : public instrument {
    public:
    void play(note) const {
       cout << "wind::play" << endl;
    }
}

void tune( instrument& i ) {
    i.play( middleC );
}

main() {
    wind flute; // new object of type wind
    tune( flute );
}


Now the output of the program is ... wind::play ... our desired output! 
Since play is virtual in the base class you can make as many new types as 
you want without having to change the tune() function. Objects 
communicate only with the base class interface and yet their correct 
class method gets called.

If you have used Visual Basic and it's classes ... you should know that 
you can create a new object as either it's type as in:

dim flute as wind

or as a generic type by saying:

dim flute as object

Dimming something as a generic "object" in Visual Basic causes late 
binding.

How can I make someone see the practical use of late binding? I can't ... 
hundreds of better programmers and writers than me have tried to explain 
the concept in books and code. But hopefully if object programming sounds 
interesting you will investigate it further and figure it out for 
yourself. 

What are the draw backs of late binding? PERFORMANCE ... plain and 
simple, if the compiler knows the explicit type of the object it can make 
optimizations. If you use the generic type ... every function call will 
involve looking for the type of the object in a table of pointers so that 
it knows exactly where to send the call.

I could go on and on for days on this subject ... and will be glad to try 
and answer any more questions. My recommendation is either don't worry 
about it or go get some books on object oriented programming. 

Visual Basic *allows* you to use some object programming techniques but 
doesn't *force* you to use them if you don't want to ... even though you 
are using them and maybe not realizing it because everytime you change a 
property of a form, button or text field in the code of your program with 
the dot notation you ARE using objects! As in ... myTextField.text = 
"This is really cool".

I'm assuming that Staz and company will still allow you to write 
procedural basic if that's what you want to do ... otherwise there will 
be ALOT of broken code out there.

Go boldly into future everyone! NO FEAR. :-)

Later,

Jon