Class Wizard issue
-
Hello, im a begginer and i did not found this question in the forums, so ill try here.
I was learning from tutorials with older version of QTIn older version when you go to Add New>C++ Class you get to put the name of the class, the Parent in this case QTcpServer and you had the option of Inherit QObject.
This would create a new myclass.h and myclass.c
in the class you would get something like this:
myclass : public QTcpServer
{
Q_OBJECT
public:
.....
signals:
......
public slots:
.....
}
And you automatically get the #include QTcpServerIn the qt .5.7.0 version i cant use base class QTcpServer because i will have to type all the rest of the body of the class and including Q_OBJect macro and manually add signals and slots member tags.
SO my question is, should i creat all classes with QOBJECT base class and the use multiple inheritance or manually change everything? i dont get why new version is not allowing this feature in older version.
-
well what version of Creator could add Q_OBJECT etc
for custom base class? 3.6 ?
I would go for change manually than
multiple inheritance.
Its only 3 places to switch baseclass.
But would be nicer if filling out the Dialog would actually work. -
@AleFachini That's weird they broke that. You don't have to use Qt Creator though, you can use any IDE you want.
CLion by jetbrains is awesome. You can use live templates and have it create your classes for you automatically.
Slickedit is another good one that has similar features.
You can even do this with just plain ole vim.
Just giving you some options if you need the pregenerated code.
As for your question you definitely want to change manually instead of multiply inheriting classes. That would be the definite wrong way to do it. It would more than likely cause issues as well since you would have a base of say QTcpServer that had a base of QObject but you would also have a QObject as your base, thus you would be inheriting 2 QObjects which I don't think would work properly when it came to memory cleanup with deleteLater() and such. I for sure would not do it that way but ymmv.