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

Question

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

Выбор и инструменты, как правило: -

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

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

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

4. Validate весь диалог, когда OK нажата, и настоящее сообщение окно (а) показывает, что это не так ,

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

Какие хорошие методы вы нашли для этого?

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

Не забудьте взглянуть на большой сессии coderage Джима: Stop Annoying Your Users!

Он имеет стих при проверке ввода ...

Answer 5

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

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

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

Answer 6

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

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

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