Open baxerus opened 4 years ago
So on your phone, it uses ',' instead of '.'? Why does everyone in the whole world have to be so different? ;)
@gb0101010101, the number input fields have that inputmode/pattern thing added to it that you did. Any idea on how to overcome this?
As I said, IMHO it is easier to "normalize" from ,
to .
in the code. I have done this often already, because if you want to take user input and do calculations in Germany (and BTW most of Europe) you have to do this.
The input field probably uses "decimal" (see examples https://css-tricks.com/everything-you-ever-wanted-to-know-about-inputmode/). But the decimal sign is based on the locale settings of the device (so it is a ,
me and, I assume, a .
for you).
You could go for "numeric", but on iOS that's actually a much worse keyboard, than what you get with "decimal". So replacing the ,
with .
in the code after you grab it from the input field, would be best from user experience side (and probably also super easy to implement).
Probably a replace(',','.')
here would be enough.
Okay, the unitSwitchZ()
should also get some care, but that's not so important.
@madgrizzle, I will check this out. It should not be too difficult. AFAIK Android and iOS automatically react to the number input so it's probably the regex that only needs fixing.
FYI, this is not going to be easy as it is not really implemented in browser form input validation. I also cannot find any Regex that will work well without creating new problems. Basically need to do validation in JavaScript.
Found Globalize JS which has:
// When no load parameter is used it detects locale from browser/system
Globalize.load();
// Setup a function to parse string number input using defualt locale
parseFloatLocale = Globalize.numberParser()
// Get the decimal version of any input string.
float = parseFloatLocale("100.123,4567")
// If locale is "de" this would return valid 100123.4567
// If locale is "en" then this returns NaN
float = parseFloatLocale("100,123.4567")
// If locale is "en" this would return valid 100123.4567
// If locale is "de" then this returns NaN
This is client side validation only. Server side would keep using standard parseFloat() and expect all numbers to be decimal using period (.) as separator for all locales.
@gb0101010101
Actually I do not see your point here. As I said before probably a replace(',','.')
at the right places (of course in the frontend) would be enough.
I mean, having an input field in the frontend for a Maslow with a decimal bigger than 1000 is already a total edge case. We are talking about daily usage via a smartphone, so the interesting input field here are the Z axis (where I had the problem) and the travel distance (where I would never enter a decimal number, because travel moves so precise aren't needed. And it's over the precision of the machine in most cases anyway). In both, especially in inch mode, you will not enter numbers so big. Second, having a user entering a decimal over 1000 as e.g. 1,478.342, so with ,
is a second total edge case.
I'm (and probably all other users) are totally okay with entering decimal with a .
and is clear, that this is the char the frontend wants there. I do so, when I'm on a computer, but when I use my iPhone I simply do not have the possibility, because the keypad only has a ,
on it. And in this case, I (and every user), will use (or at least try to use) the ,
instead, I mean there is no other char 😉.
So long story short, an added .replace(',','.')
here and there will probably fix the important cases and done.
Fixed in PR #130.
When I use WebControl on my phone I'm not able to add numbers with decimals, because my language setting is on German and the normal decimal sign here is
,
. If I answer a number with decimals, simply nothing happens, when I press the button afterwards (e.g. in the Z-axis sub-window).I see two ways to fix this:
,
by.
in the Javascript "backend" code (assuming here, that no user will enter stuff like e.g. "2,040.500" normally)