Numeric input improvement.

[GoogleCodeExporter]

I guess this sort of extends 
(https://code.google.com/p/m2tklib/issues/detail?id=139).

It would be fantastic if the methods of input for numerics could be extended.

Firstly, having rotary encoder input to cycle the number up and down would be 
fantastic (or even calling a user supplied function that increments a variable, 
so we can implement our own acceleration for skipping larger number ranges). I 
thought this would be a thing already as it really just makes sense when using 
a rotary encoder - clicking a button 120 times is a pain (and even more so when 
you can't decrement and have to "wrap around").

Secondly, input style differs between 8NUM and 32NUM and I'm not sure there's 
any reason it needs to. Perhaps a format string on the input could choose 
between having the input "click to increment" (8NUM style) or "select each 
digit" (32NUM style).

Also, with the interface between 8NUM and 32NUM, is there a reason why max and 
min values can't be defined the way they are on 32NUM? They're really quite 
handy. (same for number of columns, like 32NUM has but 8NUM doesn't). Would it 
be possibly to clean up the API here and make it more consistent?


Lastly, support for non-integer (float) input would be fantastic. I'm aware it 
can be achieved with 32NUM and some hacking, but it's the same hack that 
everyone uses (treat int as integer concatenated with decimal part and divide 
by 10^number of decimal places, then calculate a format string to display just 
this and feed it back). It seems like a very common pattern and in reality ends 
up with a fair bit of code duplication.
If this could be included in the library, I think it would be a massive help. 
Perhaps an option for amount to increment by ("0.1") or something.

Options for all numeric input types to have min, max and increment-amount would 
be just fantastic.


Thanks for all your hard work on this lib, it really is quite good, hopefully 
these suggestions can be used to add that next level of polish to it.

Original issue reported on code.google.com by [email protected] on 5 Oct 2014 at 1:29

[GoogleCodeExporter]

A lot of input, thanks for that.
Yes, indeed, somehow 8NUM and 32NUM are not consistent. I will think about 
making this more consistent.

Regarding float: 32NUM supports a decimal part already, but you need to do the 
required multipication and division. 32NUM just allows you to set a dot at a 
specific place. At least this was sufficient in a GPS applicaton.

Original comment by [email protected] on 5 Oct 2014 at 6:25