Question re: multiple inheritance with QWidgets
-
I received an unexpected error, which I don't really understand while implementing a QWidget that inherits two QWidgets. Specifically:
myqle.cpp:42:3: error: reference to 'connect' is ambiguous
connect (iow, &myIoWidget::lostFocus,
^~~~~~~Using Qt 5.15, Windows 10, mingw-w64(x86)
For background, I routinely use a small family of widgets for a fair bit of my QUI work. These are built on standard Qt widgets, such as QLineEdit, QComboBox, QSpinBox, etc. While the out-of-the-box signals and slots of these widgets are similar, they aren't quite identical. For ease of use, I implemented local versions of these that do have an identical set of signals and slots. This has mostly worked quite well for all of my apps. Unfortunately, I pay a minor price of extra programming since the widgets aren't really identical - at some point, my apps need to figure out whether they are dealing with an underlying spinbox, lineeditor, etc.
What I wanted was a simple widget that knew about my added signals, slots and something minimal about the real io widgets.
Unfortunately, Qt finds the presence of two inherited QWidgets to be ambiguous and I haven't yet figured out how to un-confuse the compiler.
To be explicit, my class declarations are like this:
class myIoWidget: public virtual QWidget {...};
class myQLE: public QLineEdit, public myIoWidget {...}
Any suggestions or pointers to what I need to better understand?
Thanks
-
Hi,
You can not inherit from several QObject based classes.
Inheriting from several widgets sounds bad. You should rather use composition.
What exactly are you trying to implement ?
[edit: added missing not SGaist]
-
Hi,
You can not inherit from several QObject based classes.
Inheriting from several widgets sounds bad. You should rather use composition.
What exactly are you trying to implement ?
[edit: added missing not SGaist]
@SGaist - not exactly sure what you mean by "use composition", but suspect you mean more or less what I've been doing so far.
Following is a description of my situation . It probably sounds more complicated than it really is, but that is often due to my attempt to balance too much versus too little detail - oh well.
In most of my apps, I have a list of objects with a significant number (more than a few, less than dozens) of elements of varying types (ints, floats, pointers to other simple types, pointers to complex types, etc). I typically build a container widget that has fields appropriate for editing each of these elements. Then I bundle a bunch of such widgets for a very convenient way of accessing/editing the individual elements. There may even be bundles of those bundles, depending on what I'm doing at the time.
Seems like it should be really easy to make the bundles (and bundles of bundles) completely unaware of the details of the specific individual field editors and their containing widgets. And that has generally been pretty straightforward. Unfortunately, it has not always been as straightforward as I hope to make the containing widgets unaware of details in the field editors.
At present, each new example of a container widget for field editors needs to know some details of the individual field editors. For example, the overall bundler wants to re-sort or re-filter the lists of displayed containers based on the values of some specific field editor. At present, that process needs to know what sort of an field editor it is dealing with.
All of my field editors share a common user interface, so I interact with them in a uniform way. But the Qt event management infrastructure needs to know some specifics - I can't just treat the field editor widgets as a bunch of QWidget* (or QObject*) becase these don't know anything about my added functionality.
I'd like to have a common base class of "field editor" that has built in everything Qt needs to know, and then to build into that class all knowledge of details of the various field editor widgets. The latter I already have. The former I don't.
Clear as mud?
-
I'm not going to talk about the design or the logic.
Just quote from the docIf 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.
So multiple inheritance with QWidgets (which are also QObjects) is not allowed unless you don't use moc.
-
Thanks to @Bonnie I fixed my last answer because there was a word missing.
Your design looks indeed very convoluted.
You seem to want some sort of auto-mutable class that does everything and the coffee.
From the looks of it you should rather have a factory that provides the right widget. A bit like that model/view architecture.
-
I'm not going to talk about the design or the logic.
Just quote from the docIf 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.
So multiple inheritance with QWidgets (which are also QObjects) is not allowed unless you don't use moc.
@Bonnie - Thank you for the documentation reference - that was very helpful.
-
Hi,
You can not inherit from several QObject based classes.
Inheriting from several widgets sounds bad. You should rather use composition.
What exactly are you trying to implement ?
[edit: added missing not SGaist]