Number/Decimal column step size should not determine validity

[Marc_Dillon]

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... 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.

Pictures to show what we’re talking about:

[Aleksi]

Thanks for this feedback… I do agree the case with this one.

[APiCC_Conor]

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

[kkelley]

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.

[Fabian_Weller]

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

[Nicolás]

Agree, we work with values such ass 180.000 185.000 or 190.350
So i wanted to use 10.000 increase decrease step but unfortunately its not posible.

[Sven_Verlinden]

I would like to have this feature interpreted this way as well.

Moreover: It would be nice to make it possible to set the increment/decrement value by formula (referenced by a value in a table).

[Rafael_ANEIC-PY]

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.

[Marc_Dillon · Accepted solution]

This request appears to have been fulfilled!

---

[Fabian_Weller]

Very cool. But it will not really add the increase step.
Here is my setting:

And this is how it looks like in my App:

[Marc_Dillon]

I see that as well.

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:

1. Round up/down to nearest step-size increments.
2. 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.

[MultiTech]

Fabian:

And this is how it looks like in my App:

If you’re wanting that decimal to increase to 2.6 you’ll need to change the step size appropriately.

0.1

[Fabian_Weller]

I want it to increase from 2.5 to 3.5. Because I set the increase/decrease step to 1.

[Steve]

The current behavior makes no sense to me.