@hskoglund I already have an underlying data store and I'm using a subclass of QAbstractTableModel to bridge it into a Qt GUI.
Making two in-memory copies of that data store and then jerry-rigging View-like synchronization between the actual data and two widget-specific data stores (plus all the requisite automated testing to make sure it works reliably) seems like the exact opposite of what I want.
@Rohith : thanks.but your solution does not work for me. I have multi button. I for example want to set image (/pic/1.png) to btn1 and then set another image to another button.
My question How to set image to them in my code behind?
don't they use QComboBox-like widgets to offer different colors, brush thickness etc?
Hm, I guess that's true, but I'd say it has more to do with QMenus and QToolButtons than QComboBox. But then again they are indeed similar in some ways. Oh well, the important thing is it's doable and quite easy ;)
@mrjj@jsulm Thanks you for your replies. As it turns out, the crash I mentioned was actually caused by a subtle, yet important bug in our test infrastructure: we have a special fixture that will instantiate and destruct the QApplication instance before respectively after each test case. We initiated the argc and argv parameters with variables local to the constructor. For some reason creating a QIcon causes Qt to access argv, in other words: a crash.
Short story: both your suggestion, but also my original approach work perfectly!