Лучший способ проверки модальных диалоговых полей?

Question

Мне часто нужны модальные диалоговые окна для редактирования свойств или параметров конфигурации приложения, но я никогда особо не рад тому, как их проверять и представлять результаты проверки пользователю.

Варианты выбора и инструменты обычно: -

1. Дизайн пользовательского интерфейса, чтобы неправильный выбор просто невозможно - т.е. использовать «Маска правок», пределы диапазона правки,

2. Попробуйте и поймайте ошибки, как они найдено - непосредственные диалоги или обратная связь, когда у пользователя есть недействительный значение, введенное где-то (хотя, потому что это может быть связано с неполная запись, это может быть отвлекает визуально)

3. Обнаружение ошибок при изменении фокус управления

4. Проверить весь диалог, когда ОК нажата, и настоящее сообщение поле (я), показывающее, что не так.

№ 4, как правило, самый простой и быстрый код, но я никогда не доволен этим.

Какие хорошие методы вы нашли, чтобы справиться с этим?

Хотя этот вопрос довольно общий, идеальный ответ будет легко осуществим в Delphi для Win32 ...

Answer 1

Как и все, это зависит. :) Я пытаюсь взглянуть на некоторые из них с точки зрения пользователя.

Номер 1. Мне лично не нравятся правки маски, но такие вещи, как ограничения диапазона для правок вращения, предварительно заполненные поля со списком и т. Д., Имеют большой смысл для общей проверки вменяемости и облегчают жизнь пользователя.

Я думаю, что номер 2 может сделать использование диалога болезненным для пользователя. Они могут не вводить информацию в том порядке, в каком вы думаете, или они могут покинуть неполное поле и вернуться к нему в конце.

Для проверки я использую комбинацию 3 и 4.

В зависимости от поля (например, требуемого значения), я могу проверять его при каждом нажатии клавиши и отключать кнопку ОК, если она недействительна. Вы можете получить фантазию и изменить цвет плохого поля или использовать какой-либо другой вид видимого контроля валидатора. Это очевидно для пользователя и не прерывает его «поток».

Вещи, которые не так легко проверить на лету (например, звонки на сервер), выполняются один раз, когда пользователь нажимает кнопку ОК.

Answer 2

Просто наблюдение, но я наблюдал, как многие пользователи заполняют диалоговые окна (особенно сложные), и они НЕ используют клавишу TAB. Они, как правило, нажимают кнопки-переключатели в редактируемых комбинациях, когда «продумывают» ответы или читают разрозненную документацию. Этот заказ не будет таким, как вы думали! Мы как программисты, надеюсь, логичны (капитан, сказал Спок), но пользователи хорошо ...

Один из способов, который хорош (но требует усилий), состоит в том, чтобы каждый редактор проверял себя при изменении или при выходе, и он просто меняет цвет, если он недействителен. Ваша процедура в коде «кнопки ОК» - это простой вопрос итерации по списку управления и установки фокуса на первый, который сообщает о себе как «недействительный», пока никто не делает.

Я работаю в авиационной отрасли с упором на кредитные карты, и у меня есть TTicketNumberEdit, TCardNumberEdit, TExpiryDateEdit, TFormOfPaymentEdit и т. Д., Потому что в некоторых из них проверка не является простой. Как уже упоминалось, вы должны приложить усилия на раннем этапе, но это окупается в сложных диалогах.

Answer 3

Не забудьте взглянуть на замечательную сессию Джима: Хватит раздражать ваших пользователей!

У него есть стих о проверке ввода ...

Answer 4

JVCL предлагает набор компонентов для проверки ввода (TJvValidators и т. Д.). Он помечает поля, которые не имеют допустимого ввода, и показывает подсказку пользователю, когда он наводит указатель мыши на этот маркер. (Я думаю, что читал о подобной функциональности в dotNET, но я никогда не использовал ее.)

Хотя мне нравится концепция, и я на самом деле использовал эти компоненты в ряде диалогов, мне не очень нравится реализация: это проблема с использованием процессора, и предопределенные валидаторы, которые поставляются с JVCL, на самом деле не являются полезно. Конечно, имея доступ к репозиторию jvcl svn, я могу просто перестать жаловаться и начать улучшать компоненты ...

Answer 5

Я думаю, что N ° 4 - лучший способ выполнить проверку, помимо того, что это самый простой и быстрый код, у вас есть вся логика проверки в одном месте, поэтому, если вам нужно подключиться к базе данных, сравните 2 + входы и т.д ... все делается только один раз,

В то время как:

N ° 1: это может быть кошмаром для реализации в некоторых случаях и для обновления
N ° 2/3: вы должны быть в курсе всех событий пользовательского интерфейса, связанных с проверкой, изменениями ввода, фокусом, .. -> тяжелое кодирование и трудная отладка

Answer 6

IMO, вариант № 1 должен быть выполнен как нечто само собой разумеющееся, а не необязательное, и интерфейс упрощен настолько, насколько вы можете это сделать, при этом позволяя пользователю вводить детали, необходимые для приложения. Однако я не люблю использовать маскированные правки. Если я хочу, чтобы пользователь ввел число, например, я просто использую текстовое поле, а затем попытаюсь проанализировать число, когда пойду сохранить значение поля.

Для прямой проверки я использую исключительно # 4, если только нет особого случая, который требует использования одного из других методов. Я хотел бы позволить моим пользователям изменять свои входные данные, если они передумают, чтобы они могли сделать ошибку и вернуться к ней и исправить ее самостоятельно, потому что они уже знают, что в их вводе есть ошибка. Тем не менее, я помогаю им, если это возможно (т. Е. Если поле формы пустое или недействительное, и они нажимают кнопку ОК, я выделю поле выбора, выбрав неправильное поле после отображения сообщения об ошибке).

Выполнение # 2 в приложении Windows Forms редко выполняется само по себе, поэтому я бы просто избегал его как основного средства проверки. Однако его можно эффективно сочетать с № 4, но я думаю, что в большинстве случаев это было бы излишним.