Dealing with the numeric keypad's decimal separator key

[jan.swaelens]

Hello,

I was wondering if there is any support or advise on dealing with the use of the decimal separator key that one can find on the numerical keypad. Depending on the country (and thus locale I assume) it should either translate in a comma or dot (as you probably are aware of).

In our case, hitting the key produces a dot in a decimal/float fields whereas users are expecting a comma to appear. At least that is what their favorite spreadsheet tool seems to do. Can we do something to cater for this expectation?

thanks
jan

[Isomorphic]

There are a couple of things to consider here.
Firstly - The character generated by a keypress on a specific key is basically OS and locale dependent.

If you explicitly switch a US-locale machine to German locale and also modify the keyboard preferences to treat the keyboard as a German layout keyboard, the decimal separator key (the dot key) in the numeric keypad does indeed generate "," (comma) characters.
So this is a native behavior.

FYI - Actually modifying the key character generated depending on the key the user pressed on a US keyboard would be difficult to achieve as the developer would need to know which actual key on the keyboard was pressed to differentiate between a period (".") from the main keyboard area and a "." from the numeric keypad, and modify the string entered into the text box.
There are techniques to uniquely identify which key was pressed using javascript but these vary by browser (and may be incomplete on some browsers) and are not wrapped with simple SmartGWT APIs. In short you'd have to either get into some deep JSNI to look at native browser event details (or possibly have us build some new capabilities into the framework to handle this).

Other than that, for float values JavaScript code works with a "." as a decimal separator, and standard APIs like "parseFloat()" won't handle a "," as a decimal separator even if your browser locale is set to "German" (thought "toLocaleString()" generates a string containing commas as the decimal separator).
So assuming you're storing out your data as numeric values rather than strings, you'd probably want to have a custom formatter on your field (for static formatting of numbers using the locale-specific formatting), and if you wanted formatted editing to work, you'd also need custom editor-formatter and parser logic (possibly all encapsulated in a SimpleType)

Regards
Isomorphic Software

[Isomorphic]

Hi again - a follow up on this:

We should mention there is a built-in capability which may help here (documented here). You can make use of the built-in SimpleTypes "localeInt", "localeFloat" and "localeCurrency" install locale-specific formatting and parsing logic.
To inherit the parsing behavior but supply a custom formatter, you can just declare a field as eg localeInt, then use dsField.format.

Regards
Isomorphic Software

[jan.swaelens]

Hello,

Thanks for the suggestions, I was just able to pick this up further now - sorry for the delay.

I have forced the locale to use ours (<meta name="gwt:property" content="locale=nl_BE">) but when I hit that decimal key on the numpad it is still yielding a dot instead of a comma. When I don't force the locale it seems to be set to 'nl' (without the country specifier), which should also work I assume. What am I still missing here? Anything that I can check to identify where this is breaking?

I also have the same behavior when I use the key in the SGWT showcase examples, given that this is something native shouldn't the key press generate a locale specific character there too?


thanks again!

[Isomorphic]

Modifying the locale will only impact the formatters/parsers we use - it won't impact the keyboard behavior. That's controlled at the Operating System level -- if you actually have your keyboard configured as a German keyboard you should see the decimal separator on the numberpad yield "," as expected when you hit that key.
As we indicated - there may be some ways to intercept this in JS and modify the character output but it's not straightforward:

FYI - Actually modifying the key character generated depending on the key the user pressed on a US keyboard would be difficult to achieve as the developer would need to know which actual key on the keyboard was pressed to differentiate between a period (".") from the main keyboard area and a "." from the numeric keypad, and modify the string entered into the text box.
There are techniques to uniquely identify which key was pressed using javascript but these vary by browser (and may be incomplete on some browsers) and are not wrapped with simple SmartGWT APIs. In short you'd have to either get into some deep JSNI to look at native browser event details (or possibly have us build some new capabilities into the framework to handle this).

Regards
Isomorphic Software

[jan.swaelens]

Hello,

Thanks, that's clear!

best regards
jan