In any event, nice blog! Steve pointed it out to me, in case you’re wondering where I came from.

The reason I want to do it this way, is because 95% of the code for my control class is the same. It’s mainly one method which reads the dialog control info from a file - the text, color, font, position, etc. So all of that code fits nicely in my base class, and from the outside I just need to call a generic LoadFromFile method, and the class does everything. The descendant classes can override this method to add any special items, like a flag for a checkbox for instance.

There are some other basic methods, like adding a bitmap, which one control might handle differently than another.

My solution to use GetCWnd() method to get the class ptr I need is not so bad. The thing I’m more unhappy about is not being able to implement message handlers such as CtlColor and OnSetCursor in the base class. If I’ve got 5 control classes, now I have 5 copies of the same handlers. I loathe redundant code, it keeps me up at night.

http://msdn2.microsoft.com/en-us/library/wcz57btd(VS.80).aspx

I finally think I understand what you’re after now though. You have a bunch of CWnd controls (like CEdit, CButton, etc), but you also want them to inherit from your common set of “Control” functionality. But your Control functionality wants to be a CWnd as well so it can manipulate the control as a base window object. However, you can’t make Control inherit from CWnd because of multiple vtables. Basically correct?

My classes are simple:

class CMyControl : virtual public CWnd {…}

class CMyEdit : public CEdit, public CMyControl {…}

The class that uses CMyControl (a dialog class, go figure) doesn’t need to know if it’s an edit control, or a checkbox control, or what. It just needs to know that it’s a “contorl” and it can go ahead and position it, or set its font, or change its color, etc. The descendant classes to CMyControl - like CMyEdit - will implement those functions. I don’t need to worry about it, because the underlying MFC controls already do those things. But, if I’m the dialog class and all I have is a pointer to CMyControl, then I need to get a hold of a pointer to the CWnd object to do those things.

Also, I don’t think you’re last statement is correct. Delcaring a pure virtual base class (I believe) is just like declaring a virtual method in a base class. Once you’ve done it, the descendants are automatically virtual whether you use the keyword or not.

You’re right that what you were describing was an interface, but I think you got the syntax slightly wrong. Simply declaring the class as virtual doesn’t make it pure virtual, which is what’s needed to make an interface in C++.

What I *think* (and I could be off-base!) you’re looking for is something more like this:

class MyControl {
virtual void MoveWindow( ... ) = 0L;
virtual void Blah( ... ) = 0L;
};

class MyAwesomeEdit : public CEdit, public MyControl {
...
};

This would allow you to pass things around as MyControl (generically), but still have concrete MFC objects under the hood. However, I may not be understanding exactly what you’re after either (damned cold!).

Oh, and another interesting thing to note: unless CEdit also declares that it inherits CWnd virtually, then you will still end up with two vtables in your CEdit subclass — one virtual, the other not. Goes to show just how evil multiple inheritance really is.

An interface is exactly what GetCWnd is. My problem is that writing somecontrol.GetCWnd()->MoveWindow(here) is far more ugly than somecontrol.MoveWindow(here).

COM is a whole other can of worms. Now you’ve got to CoCreateInstance and QueryInterface your way through nested if’s and hope your programmers are checking their returns, and freeing their bstrs and such, and fixing their cut-and-pasted sample code because 98% of it is wrong!

And tell me again how I can implement a CtlColor handler ONCE, for all 5 of my control classes?

COM doesn’t use multiple inheritance… it uses multiple interface implementations. COM is simply a set of interfaces, the concrete classes implement those. Just because a class implements multiple interfaces doesn’t mean it has multiple vtables. You don’t hit that until you get into the really crazy stuff like aggregates, inner and outer objects and the like. And they’re right, multiple inheritance is almost never needed in the real world, which is why you see a lot of languages going away from it.

Why aren’t you using interfaces instead of trying to jam multiple inheritance into the picture? It sounds like you just want to have all these classes implement a base subset of functionality, while still being concrete instances of their proper classes. So, for instance, all controls can set their position and size, and you want to reference that in a generic fashion. So make an interface which exposes that functionality generically, and be done with it. It makes no sense for a control to be both a CWnd and a CSomeOtherControl…