[Qt-interest] Optionally deriving from QWidget

MARTIN Pierre hickscorp at gmail.com
Fri Sep 16 00:23:16 CEST 2011


Hello,

> As for me  the right way  is to have 2 classes.

> One class – not derived from QWidget where you have all functionality which is not Qt dependend,
> Another can be derived from both QWidget and 1st class.
What is the point? You can have one single model class and two very distinct controllers / views. You only instanciate either or both controllers at runtime wether the GUI or Non-GUI version is required. This is just a matter of well-thinking the interfaces defining the base classes.

> There is no advantages in using preprocessor definition.
Agreed, it adds a lot of maintenance time to a project, while un-necessary in most cases.

> CMakeFiles/interactive.dir/interactive.cpp.o: In function `~Form':
> /media/portable/Examples/c++/src/QT/OptionalQt/form.h:14: undefined reference to `vtable for Form'
> /media/portable/Examples/c++/src/QT/OptionalQt/form.h:14: undefined reference to `vtable for Form'
Are you correctly pre-processing your cpp file with MOC? If yes, when you MOC your object... What is the value of the preprocessor INTERACTIVE variable?

> Is this the right way to go about this? Can anyone explain where I went wrong?
IMHO, i think you're heading the wrong way. You should read about the MVC patterns. It allows you to use the very same class (Which would be in your case your model) connected to two different views based on the GUI case. This allows you to make total abstraction of the model as long as it explorts a clear exchange format to communicate with the views it is connected to.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110916/ffcf8df9/attachment.html 


More information about the Qt-interest-old mailing list