Why cant I use my numpad anymore in 2.4.X to enter floats in a textfield?

I used 2.3.X and I'm building a new project in 2.4.2. There is a new feature build in 2.4.2 called internationalization which is set to Dutch. When a user wants to enter en float in a textfield like 45.26 it sets itself back to 4526,00. The problem is that the language is set to Dutch, so decimals in floats are separated with a comma and not with a point. So I have to type 45,26 instead of 45.26. But now I can't use my numpad anymore, this is a real problem for applications in which users have to enter a lot of float values. Users now have to use the whole keyboard instead of only the numpad and that is really irritating, and not user-friendly. And beside of that a lot of mistakes will happen when users are used to enter floats with there numpad. For example: There is an order with order lines in a datagrid with inline editing on. A user will enter his prices and amount using his numpad and tab controle, this will probably happen without really looking at the entered numbers. In this case when a user enters as a price of 987.99 and an amount of 67, the price will set itself back to 98799,00 and the amount will be the same. So the total price will be 6619533,00 instead of 66195,33, this is a difference of 6553337,67! I don't think his boss will like this difference. I think the separating feature should be configured so you can disable it on a readable textfield in a dataview. I think no user will ever enter a number separated with a point for each thousand. This way a readable textfield can behave like it did in 2.3.X, so that the numpad is usable again. Does anyone experience the same problem and what do you think of this issue?
2 answers

The problem you explain is due to the fact that the point on a numpad is used as a decimal separator. For an English notation this is correct, however, when using Dutch it still represents a point while in Dutch the decimal separator is a comma.

In the next 2.4 release (and of course in 2.5) we will fix this. The situation will be as follows:

  • When you enter a number in an input field you can use both points and comma's.
  • If you leave the field the most right point or comma will be taken as the decimal separator, all other points and comma's will be removed.
  • Based on the language of the user the number will be formatted, i.e. the right decimal separator token will be set and group separators will be added.
  • When you enter the field again the group separators will be removed and you can edit the field again in the same way as described above.

I experienced the same problem in a project, I worked around it by changing the format to 'string' and using java to replace the komma with a point.

This worked for that project but I can imagine it will cause problems when working with a lot of figures (and executing calculations on these figures) this is not practical for most cases. We'll have to ask R&D for a solution?