I found two issues related to the CTK topic ctkvalueproxy.
CTK: https://github.com/finetjul/CTK/commits/ctkvalueproxy [^]
Slicer: https://github.com/finetjul/Slicer/commits/ProxyValueForUnits [^]

1) It introduces lots of "Single Step ... is out of bounds" warning messages in Slicer's output when Slicer starts, a volume is loaded, etc.

2) It fixed the original issue 0002973, but when user types a small number with higher precision than currently displayed number, the displayed value in other fields are still not correct.
E.g.

• download MRHead. Its space origin is (86.644897460937486,-133.92860412597656,116.78569793701172) [open the file and check the meta data in its header].
• go to Volumes module, Information fields. (-86.645, 133.929, 116.786) is displayed in Image Origin field (so far, so good)
• type 133.9301 in second Image Origin field, the first Image Origin field is then updated to -86.6450. In other words, the first Image Spacing field only appends 0 at its end. Should it display -86.6449 which is the actual round-off from 86.644897460937486?

1) I'll fix it soon
2) It is a limitation of QDoubleSpinBox (and for that matter ctkDoubleSpinBox and ctkCoordinatesWidget): input values are internally rounded to the number of decimals. A solution would be to save the input value (and probably the input minimum and maximum) and trigger signals only when needed. This technique has already been done in ctkDoubleSlider (to convert from double to int). Note that now value proxy are in the game, the stored value should be the input value (before the proxy is applied).

What about setting the number of decimals doing something like:

this->setDecimals(16);

Because it will enforce 16 decimals no matter what.
So if you have 1,1,1, then it will render "1.0000000000000000, 1.0000000000000000, 1.0000000000000000" which takes a lot of space and clutter the view

But it would at least be accurate and allow us to move forward with the other issues. When done, we could then address the issue of decoupling displayed value from internal value.

An other option would be to display the truncated value in a label, and when the user click on the "link" we would popup a value editor with full precision.

I would prefer subsolution 2) (edit in a popup) rather than subsolution1)
But the time spent to implement it might be better spent in fixing the root cause.

Please try https://github.com/finetjul/Slicer/commit/14a1b7743244e3d9d665ae1497327e41f2fe7a85

Nice work! The issues in note 0009309 have been fixed.

Fixed in r22281

Closing resolved issues that have not been updated in more than 3 months