:-1: erreur : [debug/moc_configtreerow.cpp] Error 1

[Zunneh]

Hello guys, i'm working on project which contains class named CONFIGTREEROW that inherits from QTreeWidgetItem, the problem is when i enable the public slots (which contain 3 fonctions and try to build, i have this problem

and when i remove public slots, i can build it, i don't know where is the problem ?

Thanks

[SGaist]

Hi,

QTreeWidgetItem is not QObject based and if it was, you are missing the Q_OBJECT macro.

Just because a class starts with Q doesn't mean it derives from QObject. A typical example is QString. Same goes for the convenience view classes and their custom item. There's no sense in having the overhead of QObject for thing that should store only data.

[Zunneh]

@SGaist i added it and always same problem, maybe i should do multiple inherits from QTreeWidgetItem and QObject ?

[JonB]

@Zunneh
You can't just add Q_OBJECT macro into a (non-QObject) class. That doesn't make it inherit from QObject. Yes, you would have to (multiple) inherit to add QObject, if that is what you want to do.

However, I would think that what @SGaist has said about "QTreeWidgetItem is not QObject based" might make you consider whether you really want this? If the class is not already written into a project, maybe you should think again about adding QObject/signals/slots into the class you are deriving? Clearly QTreeWidgetItem leaves those to the parenting QTreeWidget, so perhaps your sub-class ought follow that principle too?

[Zunneh]

@JonB said in :-1: erreur : [debug/moc_configtreerow.cpp] Error 1:

so perhaps your sub-class ought follow that principle too?

Yes, i understand now, i have another question, when doing multiple inherits, for example QObject had a method name parent() and QTreeWidgetItem had the same Method, to call the method of QTreeWidgetItem in my program i have to use QTreeWidgtItem::parent() ?
Thanks

[JonB]

@Zunneh
Yes to your question about needing to disambiguate/resolve same-name in multi-inheritance via class::, like QTreeWidgetItem::parent().

Of course, if you redesign like we said this would not be an issue :) And if you are going to redesign, the sooner you change code instead of continuing as now the better, instead of spending time on this sort of issue!