number_input, unable to type non-integer numbers.

[David-Aguilo]

Good afternoon.
With the number_input, I am unable to type non-integer numbers. On the example provided for use of the widget, I can obtain 10.5 for example if I press the arrow up or scroll.

However, if I try to type it, I am unable to.

I think the cause is that the dot is parsed and removed before I can type what goes after it. Furthermore, I can also input a non-integer number if I type it elsewhere and copy and paste it into the application.

I don't know wether I have to enable a setting I am unaware of or if this is unimplemented functionality.

Thank you for everything.
Kind regards.

[the-marenga]

I tried to do this, when I reworked a few number_input things some time ago and there is one edge case I could not solve.

The problem becomes appending a dot, because the current value always has to be a valid number. Let say the current number is 10, we can change it to .10, which is valid (0.1) and 1.0, which is valid, but 10. would not be valid, which means nothing happens. You can solve that by artificially appending a 0 to make it 10.0 and use that value, but we have a similar problem here. The string 10.0 is the same float, as the old 10, so even though a on_changed is triggered and a message is emmited, the actual float does not change and thus will be rendered/formated as just "10" again, which means from a users perspective, the dot input was ignored. This is especially bad since this appending case is probably the most likely case for normal user input (writing a number left to right).

I only realy see two ways to make this work here.

1. Ignore appending dots and just work with the inputting dots in the middle and at the beginning
2. Force floats to always be formated with at least one decimal place (10.0), at which point inputting dots would becomes pointless

If either of them seem like a useable solution for the time being, I could add them, but I feel like they are both not great, which is why I gave up this initially

In theory there might be a 3. option involving decoupeling the text_input state&on_changed from the number_inputs, but that seems like a hard and error prone thing do do

[genusistimelord]

yeah the issue here is ignore or not. I think not ignoring might be better since on the visual side we can make it appear as with just the dot but on the numeric side we can append a .0. This generally will be better for floating point numbers. as auto placing it on the string can mess up someones typing of a number if they have not finished yet. the only other way would be to make it focused and when enter is hit to make it unfocused then to do the .0 addition and such and not check the number till then. Downside to this is you need to handle the max and min by manually clamping the number after parsing it and then changing the string to what fits.

[Redhawk18]

Do negative numbers work? I'm unsure if your able to parse the -

[genusistimelord]

• does work im just unsure if you can type it or not. The other issue is knowing if it is a float or not. I guess ill need to see if number traits has something to tell us.

I guess we can always do

  if TypeId::of::<T>() == TypeId::of::<String>() {
        println!("string={:?}", val)
    } else {
        println!("value={:?}", val)
    }

to know if it is a float or not to allow usage of . and even - in typing

[Ultraxime]

To fix these I tried to add a 0 at the end of a number that ends with a point and let the from_str method do its job to tell me if it's valid or not.
It seemed like a good idea but as the widget is always rebuilt, logically from the message on_changed, we lose the point we were trying to add because it does not exist in the value.

[genusistimelord]

The only thing we could do here Is to enforce the String to be different from the T value that is returned. This way, it doesn't matter if the String is 1.0 or 1. As they would both be the same, just displayed differently.