Enter fractional values ​​without changing the layout

How often do you have to enter fractional values ​​into the interface of any program / web service? If often, then you have probably come across inadequate behavior of such fields. For example, I quite regularly beat my forehead with absolutely stupid forms. Want to know why entering fractional values ​​can lead to a white-hot, and what to do about it? Welcome to cat.

According to my observations, the following algorithms of their behavior are most common:

• Guess where to click. Such fields are most often found in desktop applications. The field strictly filters the input of any characters except digits and the decimal separator. It would seem that everything is logical. But let's do an experiment: close your eyes and try entering a decimal separator into such a strictly field by pressing just one button. Happened? Oh, not a fact! The problem of strict filtering is that the user: a) does not know which of the two standard decimal separators was used by the developer; b) when entering numbers, one may not think about the current keyboard layout. As a result, an attempt to enter a separator in more than half of the cases fails. This is not too critical, if you need to enter one value once, but when it comes to introducing fractional numbers regularly, this behavior of the form tires.
• Neatness first. This type is more typical for the web. Input is not filtered at all, but when you try to save a form, one of the following happens: an error message is displayed; input field is cleared (or the previous value is returned); nothing happens at all (the form is checked in the background and its sending is blocked for no reason visible to the user). Apparently, some developers naively believe that the user always knows what to enter into the form.
• Well, something like that ... The third type of clumsy forms is periodically found everywhere. Predict their behavior is almost impossible. For example, in one of the good, in general, shareware-program for doing home accounting when you try to enter the wrong decimal divide (more precisely - when you press the button with the separator symbol not in the current layout) the integer part of the number disappears. In another (also far from free) utility, entering any character other than a digit and the separator expected by the program generally causes a system exception. Finally, for one very large Russian online store, entering any invalid character leads to the insertion of a decimal point and two zeros in the fractional part, and entering a point leads to ... inserting a decimal point.

In general, it's the 21st century, the interfaces are developing, and such trivial actions as entering fractional values ​​are still a headache for users. A few years ago I had a chance to design (and partially code) a small program, for users of which entering fractional values ​​was a daily task. Naturally, I did not want to repeat the behaviors described above. As a result of brief deliberation, a rather simple algorithm was born.
')
So what to do with fractional numbers? First of all, you must filter the input. Verification when sending a form is a good thing, but it is much more convenient for the user if the value is entered the first time, and not after a kick from the script. Here is my version of this filter:

1. Allow the input of numbers from 0 to 9.
2. When you press any button that carries any possible decimal separator in any layout, you need to replace the symbol sent from the keyboard so that the correct decimal separator gets into the input field.
3. blocking an attempt to enter more than one decimal separator.
4. we limit the number of characters in the fractional part of the input number depending on the type of input data.

Example 1. A user on the Russian layout consistently presses the keys [1] [2] [3] [b] [4] [5]. Result in the input field: 123.45

Example 2. The user on the English layout sequentially presses the keys [1] [2] [3] [Shift +?] [4] [5]. Result in the input field: 123.45

The result of this algorithm gives a great (wah) effect. Users no longer need to think about the layout, press Shift and guess, the programmer took the decimal point or comma for decimal. Experiments on live users have shown that after 1-2 weeks of working with such a “smart” input field, returning to regular fields causes a break and the desire to kill the programmer to break the keyboard.

Ps. Honestly, this algorithm is so simple that I am 146% sure that this approach has been used more than once or twice. But for unknown reasons, it was not widely used (if you do not believe, find the nearest input field and check its behavior - it is almost certain that it will fit into one of the three “clumsy” algorithms, and not into the “correct” result).

Pps. For those who write in Delphi or Lazarus I will provide a link to the CurrencyEdit component that implements this algorithm in the appropriate language: GitHub .

PPPS. Specific examples do not cite solely out of respect in the authors of the relevant programs. If someone from Habr's readers finds “wrong” algorithms in his code and decides to change them to “correct” - the gratitude from users is guaranteed.

PPPPS. Somehow I'm not quite in the topic: in HTML-forms, in principle, you can filter the input?