Would it be possible to set how numbers round in the number input widgets? Currently, number inputs automatically round based on the number of significant figures chosen. I would like to be able to choose how that input rounds, for example CEIL or FLOOR instead of ROUND. Would this be possible?
I ask because our company policy is to “ceil” up on all measurement values. Currently, any value being entered into the number field will automatically be rounded normally. We can add on enter key triggers to work around this issue, but our assemblers use iPads that do not require them to press the enter key.
Hi David - great suggestion to add some more flexibility here, and thanks for the context around how you would like to use rounding controls. I believe this is on our radar for future releases, but I will double check on that
I’m a product designer at Tulip focused on the App Editor and wanted to tune in here. We aren’t planning to add a feature to choose how an input rounds but the team has some exciting work to simplify and improve data validation on input widgets coming early next year.
We do have a way to “ceil” measurements values through some trigger logic (see attached). We have a CEIL() function that you can place your input’s variable in. You can either add this trigger to a button to update the input value when button pressed OR you can add the trigger to the input itself which fires off when the enter key is pressed from the input.
Our assemblers use iPads when using Tulip. On iPad, I rarely see them use the enter key because they can tap the screen to make the on screen keyboard go away. If the trigger action is “on change”, this would be a perfect solution!
I also understand the button trigger, but I personally don’t like to increase user interaction to do something that could/should be automatic.
I think I will be able to replicate a similar functionality and make it more automatic by making the CEIL() function call in a step exit trigger. My only concern with using the step exit trigger is that it is not intuitive to the user to see the value not change on input, but change when they return to the same step.
I totally understand your concern for the potential confusion for operators but would agree that it is the best solution to add the logic to the step exit trigger. Sounds like a good workaround given all the options!
