Looking for a clean solution to handle lots of SpinBox signals

[Cruz]

Hi!

I have a widget that allows the user to manipulate data with lots of QSpinBoxes. There is 20 of them! The data object is loaded by drag and drop, then all the spinboxes change to the values contained by the object. When the user tinkers with the values, the data object should be changed immidiately.

The solution I came up with is like this:
Connect the valueChanged(int) signals from all spinboxes to one inputValuesChanged() slot, that will sweep through all spinboxes, take their current values one by one and overwrite the fields of the data object.

The positive side is that I only have to write one slot. The negative side, which is not so bad, is that I change 20 fields each time something changes, although I would only need to change 1. And the really negative is side is this:

When I load the data object by drag and drop, I sweep through the fields of it and write the values into the spinboxes. As soon as the first spinbox is touched, the signal is fired and the rest of the data object is overwritten with whatever crap is currently in the spinboxes. So when I load an object, first I need to disconnect all the spinboxes, then overwrite their values and then connect them again. Blah. Unfortunately unlinke LineEdits, SpinBoxes don't have a signal that is not fired when the value is changed programatically.

Can anyone suggest a more elegant solution

Thanks
Cruz

[jpn]

Can anyone suggest a more elegant solution
Item views... :) The user is able to adjust one spinbox at time anyway. Why not provide a table of items that have spinbox as editor, one at time. It would be much more light weight and you could have a proper model backend for the data.

[Cruz]

That would be nice, but the widget is not that simple. In the center you see a 3D visualization of a skeleton. The spinboxes modify the joint angles and the skeleton moves as you press the spins. Since there is so many of them, there are visual aids needed, such as grouping with colored ornaments and positioning of the spins near the joints that are actually moved. A simple table view won't do. :(

[Jocker16]

there would exist two different solutions:
1. call sender() in the slot. This returns you the sender, of the signal or 0 if the function has been called in another way.
2. Use QSignalMapper

Qt docu says that calling sender() is not the best way, but possible (I for myself like that way, because it makes the programming not that hard :P )