[Interest] How to do it better?

[Till Oliver Knoll]

> Am 30.12.2014 um 05:24 schrieb Igor Mironchik <igor.mironchik at gmail.com>:
> 
> Hi,
> 
> 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?

Cheers,
  Oliver