Multiple inheritance from QObject (QObject is an ambiguous base of ...)

bdajeje

Hello everyone.
I already saw some topics about this problem, but don't found or don't understood any solution.

Currently I have two class, let's call them 'X' and 'Y'.
Y inherited QObject.
X inherited QLabel and Y.

As you can see there's ambiguity between QObject from QLabel and QObject from Y.

For example I have an issue when I write:
connect( X, SIGNAL( aSignal() ), this, SLOT( aSlot() ) );

Because of "QObject is an ambiguous base of X".

Is anyone have a solution for this ?

PS: I tried to dynamic_cast my X class to a QObject* but didn't change anything.

bdajeje

So, I manage to resolve my problem by dynamically casting my X class into Y class. But I don't think it's very good ... is there a better way to do ?

LarsG

Maybe if you private inherit Y ?

although I think this faq item presents your problem
http://www.parashift.com/c++-faq-lite/multiple-inheritance.html#faq-25.8

and besides changing your class structure it suggests that virtual inheritance might be a solution.

If you haven't already it might be a very good idea to read that page.

bdajeje

A private inherit doesn't seems to change anything...

And for the virtual keyword, I already thought about it but I need to be able to write the virtual word in header files. I can write into my Y class but I can't change the QLabel class ....

goetz

Multiple inheritance from QObject is not supported by Qt

bq. Citation from the "moc documentation":http://doc.qt.nokia.com/4.7/moc.html#multiple-inheritance-requires-qobject-to-be-first
If you are using multiple inheritance, moc assumes that the first inherited class is a subclass of QObject. Also, be sure that only the first inherited class is a QObject.

bdajeje

Thank you Volker :(
It's really a shame ...

goetz

No, it's a good thing™.
Multiple inheritance in general is problematic, and one should avoid it if possible.

Is i really necessary that your object Y is a QObject based class? Do you need the QObject features (signals, slots, properties)?

bdajeje

Actually I upgrade some Widget like QLabel, QLineEdit, QSpinBox etc with some new features for myself.
To do that i would create a new class, like Y class, with my new features inside.

Example: I have a class MyQLabel which inherited QLabel and my Y class.
But I can't put, like you said, signals, slots, properties inside it.

andre

Not sure what you are adding, but perhaps you can do what you want using a charm pattern? I have written a series of such widget extensions that way, and it works quite nicely.

fluca1978

[quote author="bdajeje" date="1322867452"]
Example: I have a class MyQLabel which inherited QLabel and my Y class.
But I can't put, like you said, signals, slots, properties inside it.
[/quote]

Inheritance is a very strong coupling. You should consider using composition and/or delegation. You can probably achieve the same result with a simple code.

@Andre
what is the charm pattern?

bdajeje

Thank you guys for your answers.
Andre to answer your question I'm adding new stuff like animations to my widget.
But sorry guys I don't know what is a charm pattern or even composition and/or delegation.

andre

[quote]What is the charm pattern?[/quote]

Perhaps that indeeds needs a bit of explanation. In the past, there have been examples of classes that added certain behaviour to a widget. A good example is the "FlickCharm":http://labs.qt.nokia.com/2008/11/15/flick-list-or-kinetic-scrolling/ that demonstrates adding kinetic scrolling to scroll area's. The pattern shown there can be applied much more broadly. There are many other things you can achieve in much the same way.

The basic idea is that you create a class, typically a QObject-derived class, that "magically" adds functionality to another object. That is: not through subclassing, but by instantiating a new object that manipulates how the widget looks or works. You can use things like event filters to make them work. I write them in a way that they manage their own life time, by making themselves children of the object they are supposed to act on. Futhermore, I usually make the constructor private, and create a static method like this:
@static MyCharm* MyCharm::cast(QWidget* subject) ;
@

that you use to create the charm. That allows tricks like making sure that there is only one instance of the charm in question for a single subject widget.

Working this way is quite a powerful programming pattern. It allows you to change the behavior in lots of little but very useful ways, without subclassing. The charm can often apply to multiple types of widgets, and it prevents an explosion of derived types.

Examples of charms I have written, are:

A charm to enable verifying of the contents of tabs before allowing a tab change in QTabBar or QTabWidget
A charm to make it possible to rename tabs of QTabBar or QTabWidget
A charm to add small inline command buttons inside or outside a QLineEdit or a QComboBox. You can cast this charm multiple times to add multiple buttons.
A charm to make the selection list of a QComboBox wrap around.

For this way of programming, Qt offers some very powerful tools to make this possible, especially the event filter. I call this the charm pattern.