QtForum.org

I am currently trying to build a set of custom widgets that add additional functionality to the standard QWidget. Each widget has its own set of functions which are different from the rest, and they also have a set of functions that be will the same across all of the custom widgets. This problem is crying out "Use multiple inheritance." Using multiple inheritance will allow me to create a base class, that all of my custom widgets can inherit, which would add the additional functions that are the same throughout all the widgets, without having to write the same code over and over. This setup was working great until I needed to use Signals and Slots in my base class. To do this, the bass class must inherit QObject, and since QObjects are not inherited virtually, this cannot be done.

This seems like a huge limitation to Qt because the end result is, I have to code the signals and slots functions, multiple times, across all the custom widgets. Regardless of the fact that the code is generic, and identical. Seems to me, if the QObjects are to be setup so that you cannot use mutliple inheritance of qobject, then the singals and slots should not be dependent of qobjects. This way you can use signals and slots in other classes.

The reason for this post is not to bash Qt (since this is by far my favorite developing tool yet), but rather a question as to how can I get around this limitation. Or am I simply not seeing the big picture. My problem though is a valid one. How can I turn classes into peices of a larger whole, adding functionality to a parent class much like adding another module to your kernel, and still be able to use signals and slots.

Unfortianitly I can't go into huge details about what I am doing (Government stuff), but here is an idea of what I have

Core product object starts with,

class CoreWidget1: public QWidget
{}

class Core Widget2: public QWidget
{}

I can't change CoreWidgets 1 and 2, but I can inherit them, and add things I need for my project. So I have

class Common: public QObject //for signals and slots

class myWidget1: public CoreWidget1, public Common
{}

class myWidget2: public CoreWidget2, public Common
{}

Like I said this worked great until I made Common a derivative of QObject to be able to use signals and slots.

The virtual idea is what should be done, but won't work because QObject wasn't a vitual class to begin with.

One thing I noticed is that if I add singals, and slots to my class, without it Inheriting QObject, the compiler does complain. I would imagine that the singals and slots simply won't work if you used Common as you base class. However, and this is what I want to see, is if the signals and slots start to work if I inherit Common, and a class that is derived from QObject.

As for the boost link, it doesn't work..

Thanks guys...... I will let you know what I find, if you have more suggestions, keep them coming.

If I change Qt's classes to be virtual, how will that effect the overall functionaility though. I mean, this Qt stuff is pretty slick. I would imagine that the Qt developers didn't make the classes virtual for a reason.

If you do this it works fine (except when common is a QObject... which is the reason for this thread)

class Common

class myWidget1: public QLineEdit, public Common
class myWidget2: public QLabel, public Common

So far I am still trying to create an environment where I can test your above suggestions.

Good call VirtualBrainSucker! So far all of my testing has shown that your previous idea works. I will get back with further detail later,

Thanks

Well the final result is that this can not be done. The above ideas are all great except that the Common class cannot call a signal unless it is in the Common class. So what really is going on here is a poor design. It would be nice to be able to creat pieces to a puzzle, and then when a class wants that piece, I simply inherit that piece and "PUFF", it works. But this has proven to be a limitation of C++, not Qt. See, even if Qt had virtual QObject classes, I would still have to capture the event that causes the signal to be emited. This event is part of a QWidget. And if I overload the event in the Common class, I now have two instances of this event. There for the class inheriting these two classes needs to resolve this ambiguity. Therfore, work has to be done to allow these two pieces to be inherited together. Thereby killing my hopes of simply add the extra class and be done. It has also proven easier to simply add the functionality I wanted to the CoreWidget class manually. Even though this is against the idea of not writing the same code more than once, C++ realy didn't give me a choice here. Thank you for all your help, sorry to someone else who ran into a similar problem, however I would re-think your design approach and ask, is what I want to do really going to help! It didn't in my case. Great forum response though!!! Really impressed. Thanks guys

Rian

This major issue is more than just signals and slots. The signal being produce is emitted from a closeEvent () function which is QWidget function. If I use signals and slots, the signal has to emited from class that signal. For this idea to work, I would have to be able to emit the signal from another class that defines the signal. This is the major reason why I believe my deisng is flaued.

Absolutely... If you think it can be done. It minimum this would help to better educate anyone else who might read this thread, as well as help to clean up my code .