When you have a number or decimal column where you specify an increase/decrease step size, it seems that this causes some internal validity check that any manually entered inputs must be a multiple of the step size. This seems extraneous given that we can already specify our own valid_if expression to cover this if we want, and I see no reason why this should always be forced.
Consider a situation where you need to allow decimal inputs to a column, however most of the time the inputs are just integers. You may want to specify 2 decimal places, and also a step size of 1 to give your users convenience when inputting. This is currently not possible.
See this post for reference:
[So I've got a decimal type column, which 2 de...](https://community.appsheet.com/t/so-ive-got-a-decimal-type-column-which-2-de/1563/11) Questions
Does anyone have any additional feedback on Marc’s issue? The behavior he describes that he was expecting is what I expected as well. It seems to me that the Increase/decrease step function should not be coupled with the validity of the number, it should just change the way that the + and - buttons work.
If we could get this resolved it would save my users quite a bit of time by making the + and - buttons more relevant. Currently most of our decimal inputs allow for two decimal places, but they have to manually type just about every number because the + and - buttons only go up in increments of .01
I agree. I think I posted about the need for this quite awhile ago. We put in an estimated value for preseason calculations, but want to put in a 2 decimal final value post completion. The +/- buttons aren’t useful to us right now. We start with 220 but may end up 233.87.
We also very need this thank you @Marc_Dillon.
In most of the times we need the + button to just increase by 1.
But we schould also have the possibility to enter for example 1.5
I hope they patch this eventually, having to choose between using decimal digits or having useful +/- buttons doesn’t feel like the intended design choices we’re supposed to have.
I think that just comes down to a difference in thought about what the step-size means.
It obviously knows what the currently entered value is. At which point that just comes down to a design decision between 2 choices:
Round up/down to nearest step-size increments.
Add/subtract step-size from current value.
I don’t think either of those options is obviously better than the other, and at this time I think I’m leaning towards #1 being slightly more useful. Though that could change the next time I use it, but not something I’d waste a feature vote on, so to speak.
