Hello Sergey, Alexey and Pankaj, I am reading the current discussion and I was thinking about an idea changing the code in the way that instead of working with float/double numbers we work with integer ticks. For example, the model remembers the min/max/step values and calculates a number of steps required to reach from min to max. All increment/decrement actions are done against the current ˋtickˋ value. If the current ˋtickˋ reaches 0 - we return min; if maxTick — we return max. And the current value can be always counted as (min + tick * step) if tick is neither zero, nor max tick count.
At least if we deal with integer ticks, but all reading operations calculate on the fly, we will be able to control the representativeness of output. As always, I don’t know all the details and possible consequences, so feel free to ignore my email, if I am wrong. Kind regards, Vlad Sent from myPad > On 13. Feb 2020, at 22:34, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > On 2/12/20 8:21 am, Alexey Ivanov wrote: >> The bug report says that going from -0.15 to -0.10 does not allow going back >> to -0.15. This happens because the result of this sequence of operations >> cannot be represented exactly, or, in other words, because of rounding >> errors; or rather the result is less than the set minimal value. >> Can we set the value of the spinner to the set minimal value instead of >> disallowing the operation. I mean, after going up the displayed value is >> -0.10; going down by 0.05 gives the result which is less than the minimal >> value for the spinner, and thus going down is not allowed. What if we set >> the value of the spinner to its minimal value instead? > > In this case, we will need to update all types including int. Isn't it will > be surprised that the spinner will show the value which is not calculated as > "defaultValue + stepValue * stepCount"? > > > -- > Best regards, Sergey.
