[Interest] How to do it better?
Till Oliver Knoll
till.oliver.knoll at gmail.com
Tue Dec 30 09:41:05 CET 2014
> Am 30.12.2014 um 05:24 schrieb Igor Mironchik <igor.mironchik at gmail.com>:
> cool, after a whole day of work
My whiskey tasted great yesterday evening (also after a day of work, and after a great self-made dinner with friends).
> my brain is clouded.
Ah, I wasn't aware that you were looking for a Cloud(tm)-based solution!
Ok, whiskey and jokes aside: your base class could also simply emit a Qt signal (to relate this thread a little bit with Qt) whenever that property changed (again, setter/getter accesss, make sure the property actually /did/ change before emitting the signal, ... you know the game).
Your derived class could then simply connect "to itself" (to that signal) and react accordingly in its own slot.
But I have to ask: for me it sounds like your base class is some kind of "data" (Model) class, and your derived class a QWidget-based class, aka "the View" (you've mentioned QResizeEvent). Or in other words: does your derived class inherit from two base classes: your "Model" and some QWidget class (multiple inheritance)?
If yes: why not a "has-a" relationship between your Model (currently your "base class") and your View (currently your "derived class"), instead of your current "is-a" situation?
If no, then why does your base class (which must then be a QWidget based one in this case) not handle the resize event itself; derived classes could still overwrite the resize method and add custom code, e.g. after (or before) calling the base class' resize method?
More information about the Interest