I love button, slider, dial, etc. options… each has a purpose and advantage/disadvantage.
Yep… to optimise use of most any widget is to use code 
My motivation is far from being “don’t want to use any code”. I’m happy to reprogram everything to have the precision I need.
My problem is in visualization and user interface. I don’t want a value that is 0.0001 to be represented as 0.01 and I need to remember it was multiplied by 100.
It’s like saying why don’t you represent the temperature multiplied by 100 (centidegrees), so that in your application you see 25 degrees represented as 2500. Would you like it? It’s not user friendly.
This! And since step can have integers AND float I don’t get why slider shouldn’t.
To get back to the OP issue… I just tested this and it still works just as you described… Aside from the number shown on the slide, the output value in the code is still 0,1,2,3,4… with the usual param.asInt()
So, when moving the slider, just go by the first digit before the decimal as that is the integer output… even the physical slider position is the same.
What % of users do you think need 5dp?
I don’t have any statistics. I know that the app was downloaded more than 100k times and I don’t think the 5-6 people writing on this forum can decide for 100k users. The developers should understand if it is worth or not.
But once the float is supported what’s the difference between 2dp and 5dp? Why exclude possible application even if 1% or 0.1%?
I think we are missing the point from a UI perspective. If you change the functionality of something that is in production and it isn’t backwards compatible you risk causing users issues regardless of how they chose to use it. This is just user interface 101…
Just my humble opinion.
2 Likes
Totally agree! 
I can’t see where anyone has shown that the change doesn’t adhere to GUI 101 as param.asInt() still works as it always has.
If anyone has a “broken” project please explain how and I might even send them a link to the earlier apk.
I have horizontal sliders with ranger 0 to 1, to emulate the horizontal sliders in the settings menus. They now get stuck in intermediate states. 
@omegab sorry I don’t understand.
You were using a slider with expected values of 0 and 1.
New app still provides 0 and 1.
Were you not using param.asInt() before?
Same problem as omegab notwithstanding the use of param.asint().
I replaced the sliders in my project with “menus”. Not as user friendly but I needed a solution pending the resolution of the slider issue.
Can someone provide a code snippet that now fails.
1 Like
Probably need to show an operational issue first, one that is not simply a visual floating point number shown on the slider widget. I have already tested and confirmed there is no operational change in the integer output value with a range of 0-4 (or any range).
When @Dmitriy said:
It didn’t really register with me that this would include button widgets, but it seems that this is the case and is causing a few issues for Node-Red users:
It’s easy enough to work around, but a bit of an inconvenience. I don’t know if the issue of a button widget not accepting 0.0 as an Off command is a peculiarity of the Node-Red implementation, or a bug in the latest Android release. I don’t have an Android device to test this on, but if passing a float value of 0.0 to a button widget from code doesn’t turn it off then it may catch some non Node-Red users out.
I’m still not clear why a switch widget with a binary state need the ability to use floats though!
Pete.
2 Likes
Thank you all for feedback. We will introduce additional settings to the slider that will allow set the slider step precision so this will make the slider to work as before. Sorry for any inconveniences.
6 Likes
With increased resolution also?
Great thank you!
Hi @Dmitriy.
Just a bit more on my post. From a UI point of view the upgrade to the slider now makes it very difficult to get the exact value one requires. A resolution of 0.01 is too much for my finger to control. I know my code and device will be converting to an integer and using an integer but the app will display the closest value I can get with my finger on the slider to a resolution of 0.01. It’s a bit messy and the change is a bit of a surprise.
Now that we can have a float could you please consider adding another attribute to the slider configuration which will allow the specification of an increment and a display resolution. For instance if I specify 0.5 then the increment will be 0.5 with a display resolution of 1 decimal place. If I specify 1 then the increment will be 1 with no decimal places displayed.
My preference is to use the slider rather than the stepper because cosmetically I like the slider better as I explained previously. That is my personal preference and opinion.
I would welcome the thoughts of other users of the slider.
Thanks.