| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Обработка неверно введеного значения [D6, D7, WinXP]
venoel © (2008-12-11 12:59:00)Здравствуйте. Хочется услышать ваше мнения и советов по следующему вопросу.
Исходная ситуация. Есть элемент ввода. Пусть вводимое значение должно удовлетворять какому-то условию. Вопрос собственно в том, что делать, если введеное значение условию не удовлетворяет. В коллективе мнения разделились.
Мнение раз: Надо сообщать пользователю об ошибке и возвращать фокус ввода на элемент ввода (что на мой взгляд неудобно и лишает возможности воспользоваться другими элементами окна, до тех пор, пока не введешь "правильное" значение).
Мнение два: сообщать пользователю об ошибке, но позволять покинуть поле ввода (естественно с невозможностью все таки в дальнейшем записать неверное значение в БД).
Хотелось бы услышать, кто как решает данный момент.
Медвежонок Пятачок (2008-12-11 16:38:00) [21]юзер имеет право начать ввод документа в понедельник, а закончить в пятницу. с закрыванием формы и программы и с сохранением всех уже введенных значений в том числе если что-то не заполнено.
venoel (2008-12-11 14:12:00) [22]не, тут вопрос не в "гарантии", а именно в "поведении" программы.
Ну качестве наглядного "не хорошего поведения программы", можно взять DateTimePicker. Если там по умолчанию стоит дата из месяца сентябрь(или февраль, апрель, июнь, ноябрь), а вам надо ввести 31.10.2008, то вам надо перевести фокус ввода на "месяц", исправить месяц с 09 на 10, потом пернуться на "дни" и тогда уж вводить "31" число.
Ega23 (2008-12-11 13:59:00) [23]100% гарантию может дать только процедура проверки ВСЕХ значений после нажатия OK (но перед запуздыриванием в БД).
venoel (2008-12-11 13:42:00) [24]ну мне кажется весь диапазон возможных вариантов был перебран. Спасибо.
Юрий Зотов (2008-12-11 13:10:00) [25]Естественно, проверка ВСЕХ значенией должна идти при нажатии OK, а не при потере фокуса каждым контролом. Помимо удобства для юзера, это еще и дает возможность проверять данные в их СОВОКУПНОСТИ.
Сергей М. (2008-12-11 13:04:00) [26]imho, оба решения имеют право на жизнь.
Выбор того или иного зависит от дальнейшего хода алгоритма и от конкретных требований пользователя по удобству/функциональности интерфейса и по реализации защиты от дурака.
Можно поступить и иначе - предусмотреть польз.настройки, меняющие поведение проверочных участков алгоритма удобным для юзера образом, если это не противоречит сквозной логике..
clickmaker (2008-12-11 13:03:00) [27]> Надо сообщать пользователю об ошибке и возвращать фокус
> ввода на элемент ввода
но не в момент, когда он покинул именно это поле ввода, а когда нажал кнопку Ок или Применить или что там еще
Можно еще выводить что-то типа хинта с сообщением о неверности данных, указывающего на это поле ввода.
Если значение должно соответствовать каким-то определенным требованиям, лучше писать под полем ввода примечание. Типа "Логин должен состоять только из латинских букв"
Юрий Зотов (2008-12-11 13:03:00) [28].. что на мой взгляд удобно, так как избавляет пользователя от лишних умодвижений (какой именно контрол содержит неверное значение) и телодвижений (фокусировки этого контрола).
| |
Страницы: 