Multiple inheritance from QObject (QObject is an ambiguous base of ...)
-
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.8and 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.
-
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. -
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. -
[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? -
[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.