So I've got a decimal type column, which 2 de...

[Marc_Dillon]

So I’ve got a decimal type column, which 2 decimal places specified. I then set the valid_if field to be greater or equal to zero, and a message to display if not “Enter only positive values”. That’s all good.

But then I went and set a step size of 1, thinking that it would make using the + and - buttons easier, depending on what the user entered. I would also expect it to simply add or subtract 1 from any decimal number entered. However this made appsheet think that any numbers with decimals were not valid, and also displayed the same message as described above, even though the entered decimal values were positive.

Is this how it is supposed to behave? I would definitely prefer it to behave like I was expecting.

[Michael2]

I think I ran into this before as well and the solution was to enter 0.1 as the step value…

[Marc_Dillon]

Yah, that allows the use of the first decimal place, but then trying to use the 2nd decimal place becomes invalid.

[Michael2]

@Marc_Dillon Okay well, what happens if you used 0.01 as the step instead of 0.1?

[Marc_Dillon]

Then the + and - buttons are basically useless, it takes less time for the user to open the keyboard and input their value. I want the buttons to increase and decrease by 1 for those times when the user only needs to input a whole integer.

[Michael2]

@Marc_Dillon I couldn’t agree more but, that’s what we’re working with. Maybe @praveen or @Philip_Garrett_Appshcould shed some light here?..

[Levent_KULACOGL]

@Marc_Dillon to increase a decimal type value by steps, you should use 1.00

[Marc_Dillon]

@Levent_KULACOGLU That is not correct. Appsheet just changes the step value back from 1.00 to 1, and it works the same.

[Michael2]

@Marc_Dillon To clarify, ‘it works the same’ you mean, after specifying the step as 1.00 and then entering for example 0.01 in the form, AppSheet says 0.01 is invalid?

[Marc_Dillon]

Yes, entering 1.00 as the step value works the same as entering 1, with any decimal number entered being invalid.

[APiCC_Conor]

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.

[Bahbus]

While I am unsure if this original issue was ever solved, I have a possible idea not discussed here. If you have a Valid If expression similar to Marc’s of >=0, I’m wondering if Marc tried >=0.0. And likewise for you, check to see if your using a decimal or an integer in the Valid If. If integer, try a decimal version.

[APiCC_Conor]

In my case I don’t actually have a valid_if statement. The issue is that even though my column type is decimal with 3 decimal place, if I set the increase/decrease step to 1 then all decimal values become invalid.

Also, you can’t add a trailing zero or decimal to the Increase/decrease step to make it work either. For example 1.000 just auto corrects to 1

[Marc_Dillon]

Thanks for the reminder about this old issue. No, it was never addressed. I think a feature request post is in order.

Number/Decimal column step size should not determine validity Questions

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 i…

[Makcharlie]

If you want it to be into 2 decimal places then you should set the incres/decrease step size to 0.01, if you want it to allow up to 3 decimal places, then set the increase/decrease step size to 0.001

[eshann]

good post like it