Такой вариант тоже возможен. Единственный нюанс — если введённые данные дальше попадают в SQL-запрос, то при отправке формы запятую придётся либо заменить, либо экранировать.
Кстати, в случае с ноутбуком быстрый ввод десятичного разделителя представляет собой ещё большую проблему — встречал модели, у которых клавиша "?/.," была сдвинута.
Ну и нумпады есть далеко не у всех моделей, да.
Я с ходу не смог вспомнить ни одного приложения, где бы мне приходилось вручную вводить разделители разрядов. Но в целом, согласен — такой случай мой алгоритм не обработает. Можно попытаться его адаптировать, но, как минимум, нужно проверять системные настройки (разделители) и уже от них плясать.
Вот именно эту проблему решает предложенный алгоритм, позволяя вводить числа без нумпада, не сбиваясь на переключение раскладки и нажатие Shift для ввода разделителя.
Попробуйте в реальной задаче использовать такой фильтр — и убедитесь, насколько быстро к нему привыкаешь.
Когда попеременно ведётся ввод текста и числовых данных большинство пользователей предпочитает не прыгать рукой к нумпаду. Но мы же не можем принудить всех пользователей использовать строго нумпад, поэтому проблема ввода разделителя с основного поля актуальна.
На самом деле это очень спорный вопрос. Я проверял на реальных пользователях оба варианта (информирование о неправильном вводе и фильтрацию). Конкретно в случае с вводом дробных значений фильтрация более лояльно воспринимается пользователями. Фактический предложенный алгоритм — это не просто фильтрация, а коррекция ошибок ввода.
Не думаю, что тут будут проблемы — разделитесь групп разрядов отрисовывается на уровне API операционной системы и от вводимых символов мало зависит. Конкретно мой код для Lazarus (специально сейчас проверил) вообще не реагирует на смену системного разделителя — поле ввода имеет текстовый формат.
В целом же, мой алгоритм ориентирован на типичные для русскоязычных пользователей случаи. В случае с использованием раскладок, отличных от RUS/ENG, алгоритм нужно проверять и, вероятно, немного изменять.
Ну и нумпады есть далеко не у всех моделей, да.
Что касается ввода в экспоненциальном виде — это тоже не проблема, но в моём случае такой задачи не было, требовался ввод финансовых значений.
Попробуйте в реальной задаче использовать такой фильтр — и убедитесь, насколько быстро к нему привыкаешь.
В целом же, мой алгоритм ориентирован на типичные для русскоязычных пользователей случаи. В случае с использованием раскладок, отличных от RUS/ENG, алгоритм нужно проверять и, вероятно, немного изменять.