Just like the Button class and Button::clicked(), the ComboBox class should have a virtual function ComboBox::itemChosen() (or any other suitable name) that is called when an item is selected. This way, subclasses can be self contained without the need for adding themselves as a listener.
Now if this already exists, my apologies (but I don’t see anything virtual in the class).
I haven’t looked but of course this applies to any control that can have a listener attached for notifications.
hmm, well… no, not really. I don’t like the idea of encouraging subclasses that actually respond to the user’s actions - I understand that you might sometimes need to create a subclass to customise a control’s appearance, but the subclass is the wrong place to actually respond to events.
I don’t really like the Button::clicked method either, but it’s mainly there for historical reasons. I don’t think I’ve ever used it in an app.
In my app all controls are completely self contained, there is no central Component that processes user interface actions. Controls can appear, get duplicated, and disappear in response to scripting events so the layout of the interface is not precisely known at runtime. Why is a subclass the wrong way to handle this? I’m always willing to learn something new.
Well, it’s just good practice to separate your program logic from the UI. Ever heard of model/view/controller? I don’t normally go as far as a fully-segregated MVC design when I’m coding stuff, but I do at least keep my model in a different class to the components!
