Давно хотел написать — про валидацию пользовательского ввода. Стоило бы наверное написать статью, но все как-то не до того…


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

Валидация предполагает не только проверку, но и сообщение пользователю о результатах такой проверки. Обычно результат проверки представляется пользователю в виде стандартного окна-сообщения (message box) с кнопкой ОК. Такой подход хоть и является общепринятым, но имеет ряд недостатков.
Во-первых, сообщение обычно говорит только об одном поле и одном значении. А это значит, что пока вы дойдете до результата, вам придется несколько раз нажимать ОК и несколько раз получать сообщения о неправильном значении. Вы не видите всех полей, которые требуется заполнить или исправить — а значит, вам придется узнавать о таких полях, накапливая опыт работы с программой путем проб и ошибок.
Во-вторых, окно сообщения нужно каждый раз закрывать — это неудобно и отнимает время. После закрытия окна нужно найти поле, о котором говорилось в сообщении (даже если фокус переведен на это поле, вы должны найти его глазами), и исправить его так как было сказано — но сообщения вы уже не видите.
В-третьих, многие рядовые пользователи просто ненавидят сообщения об ошибках. Им не нравится, что машина указывает на ошибки человека.

Итак, существующий способ валидации по крайней мере неудобен.

Неудачное решение: ограничение ввода. Иногда данную проблему решают за счет более жестких ограничений при вводе. Например, если в поле вводится число, то все неподходящие символы вообще не вводятся. Для жестко форматированных значений (телефонные номера, почтовые индексы, номера счетов) используется MaskEditControl, который не позволит ввести текст никак иначе кроме как по заданной маске.

Такой подход мне не совсем не нравится — по той причине, что он по сути «замалчивает» проблему — вместо сообщения об ошибке пользователь теперь получает неприятный звук при нажатии «не той» клавиши. А это означает, что снижается само-описательность системы, и как следствие — возможность само-обучения для пользователя.
Единственное что я приемлю в качестве ограничения — ограничение по длине в текстовых полях: ввел текст максимальной длины — не можешь больше вводить. И то только потому что другие решения были бы еще хуже — например, сообщение «вы ввели на 17 символов больше чем допустимо в этом поле»…

Решение: ненавязчивая валидация. Работая над очередным приложением (под VB.NET, несколько лет назад), я пришел к мысли, что с валидацией нужно что-то менять. Основная идея заключалась в том, чтобы отказаться от окон сообщений. Но чем их заменить? Можно было бы снабдить каждый диалог строкой подсказки (status bar), но это изменит стандартный облик диалога и не решит всех проблем.

Другая мысль была в том, чтобы подсвечивать поля, содержащие неправильные значения — например, сменой фона контролов со стандартного на какой-либо другой. Оставалось решить как показывать сообщения. Рассмотрев несколько вариантов, в конце концов я остановился на тултипах (tooltips).

В общем, последние несколько лет я придерживаюсь такой идеологии валидации:
1. Пользователь может вводить в поля все что хочет.
2. Непосредственно при вводе (при изменении значения в поле) выполняется проверка валидности значения в поле. Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.
3. Невалидные поля подсвечиваются светло-красным. Этот цвет — не константа, а вычисляется на основании цветов текущей цветовой схемы.
4. При наведении мыши на невалидное поле появляется тултип с очень коротким описанием проблемы и ограничений.
5. Запрещенные (disabled) и невидимые (hidden/invisible) поля не могут быть невалидными.
5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».
6. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.

До сих пор эта методика себя оправдывала. Использовались ее реализации под VB.NET/C#/VB6.

Здравствуйте, nzeemin, Вы писали:

N>1. Пользователь может вводить в поля все что хочет.

Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

Здравствуйте, nzeemin, Вы писали:

N>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».

Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

Здравствуйте, olegkr, Вы писали:

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

Её тоже нужно подсвечивать красным. Типа, "выход есть, но не сейчас".
Задисабленная кнопка ОК создаёт впечатление неряшливого разработчика — как будто он взял шаблон другого диалога, а функцию ОК отключил.

Здравствуйте, olegkr, Вы писали:

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

Да-да, сначала я тоже так думал. И запрещал эту кнопку, пока пользователь не заполнит все поля как надо. Но практика показала, что многие пользователи не могут (сразу либо без посторонней помощи) разобраться — почему кнопка не включается. Действительно, здесь нужно установить связь между кнопкой ОК и подсвеченными полями. Если кнопка разрешена — пользователь нажимает ее и видит поясняющее сообщение — после этого ему становится легче установить эту связь. Программа становится более "self-described"...

Здравствуйте, yoriсk.kiev.ua, Вы писали:

N>>1. Пользователь может вводить в поля все что хочет.

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

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

Мне нравится, когда приложение (в ненавязчивой форме) само дает мне понять как с ним работать, но при этом не держит меня в жестких рамках. Например, дату можно вводить (а также — копировать из других приложений) в форматах ДД.ММ.ГГГГ или ДД.ММ.ГГ или ДД.ММ (сокращение для даты текущего года). В моем подходе это легко реализуется, в вашем — вы ограничены только одним форматом.

Здравствуйте, Кодт, Вы писали:

O>>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.

К>Её тоже нужно подсвечивать красным. Типа, "выход есть, но не сейчас".
К>Задисабленная кнопка ОК создаёт впечатление неряшливого разработчика — как будто он взял шаблон другого диалога, а функцию ОК отключил.

Вообще — мысль неплохая...
Есть еще некоторая проблема с TabControl — когда невалидные контролы находятся на других вкладках. В этом случае неплохо было бы подсвечивать соответствующие заголовки вкладок.

Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, nzeemin, Вы писали:

N>>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.


1) Вы заменили "неприятный звук при нажатии «не той» клавиши" на ее подсвечивание. Не клавиши, разумеется, поля 8))
2) Вы заменили MaskEdit(большим достоинством которого я считаю возможность сразу понять требуемый формат ввода(для пользователя, который редко пользхуется формой) и ненужность вручную писать сепараторы и пр. служебные символы — для оператора — ну зачем ему, к примеру, вставлять слеши в дате?) на что-то, что неопытному пользователю расскажет об ошибке когда-нибуть потом(а до этого он, что, догадываться должен, что в нашей форме год надо обозначать двумя цифрами?) а от оператора требует дополнительного ввода(что увеличивает возможность ошибки да и просто снижает его производительность).


В чем выигрыш?

Кроме того, ошибки ввода неопытному пользователю не всегда видны. Маскедит не даст поставить лишний пробел, не позволит написать сумму прописью, написать копейки через запятую. А вы сообщите типом, "Ошибка во вводе цены", а несчастный юзер никогда не догадается, что гривны и копейки надо разделять точкой.

Вообще, ИМХО чем меньше "Пользователь может вводить в поля все что хочет", тем лучше.


Под "оператором" я понимаю пользователя, который профессионально исспользует программу.

Здравствуйте, nzeemin, Вы писали:

N>Мне нравится, когда приложение (в ненавязчивой форме) само дает мне понять как с ним работать, но при этом не держит меня в жестких рамках. Например, дату можно вводить (а также — копировать из других приложений) в форматах ДД.ММ.ГГГГ или ДД.ММ.ГГ или ДД.ММ (сокращение для даты текущего года). В моем подходе это легко реализуется, в вашем — вы ограничены только одним форматом.

Вот этого вообще не понимаю. Получаем "01.02.03". И что мы будем делать с этой датой? Опять же, проверять, не вписал ли он 01-10-01 или 01/01/01 и рассказывать, что это ошибка?

А ведь пользователи — люди крейне изобретательный. Они вам и О1.О3.2ОО5 напишут... А потом прийдет невразумительній багрепорт "Неправильно вводдится дата" :super: :maniac:

Не, я за то, чтоб чем меньше свободы во вводе, тем лучше.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Здравствуйте, nzeemin, Вы писали:

N>>1. Пользователь может вводить в поля все что хочет.

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
Ненавижу MaskEdit Оснавная причина --- не возможно свободно редактировать поле: делать вставку из буффера, нельзя добавить новый символ, не удалив другой и т.д.

Здравствуйте, olegkr, Вы писали:

O>Здравствуйте, nzeemin, Вы писали:

N>>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».

O>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.
На то есть пару причин. Первая -- неоправданная сложность кода --- необходимо обрабатывать сообщения об изменении полей пользователем, то есть нажатия enter, смену фокуса и пр...
ВО-вторых, иногда процесс проверки валидности поля очень длительный, например ввод хоста и проверки его доступности или какие нибудь сложные математические расчеты. Поэтому иногда удобнее делать валидацию только по нажатию кноки ОК.
Есть еще один случай когда рантаймовскую валидацию использовать не следует. А имеено, когда диапазон вводимых значений зависит от значения введенного в другое поле. В этом случае, пользователь может увидеть знаки что все плохо, когда он еще не польностью ввел значения, что в свою очередь может пользователя заканфузить.

Здравствуйте, nzeemin, Вы писали:

N>6. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.

Небольшое дополнение — иллюстрация того как выглядит выбор даты (здесь показан ввод неверного значения, нажатие пикера и выбор даты из пикера):



Конечно, надпись на тултипе надо сделать подробнее. Например: "Неверная дата. Используйте формат ДД.ММ.ГГГГ или ДД.ММ.ГГ."

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

Более того! Если это правильный maskEdit, то разделители и вводить не надо! Юзер вводит только цифирки и все. Экономия времени и нервов пользователя.

Здравствуйте, nzeemin, Вы писали:

Спасибо за поднятую тему

N>В общем, последние несколько лет я придерживаюсь такой идеологии валидации:
N>1. Пользователь может вводить в поля все что хочет.
N>2. Непосредственно при вводе (при изменении значения в поле) выполняется проверка валидности значения в поле. Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.
N>3. Невалидные поля подсвечиваются светло-красным. Этот цвет — не константа, а вычисляется на основании цветов текущей цветовой схемы.
N>4. При наведении мыши на невалидное поле появляется тултип с очень коротким описанием проблемы и ограничений.
N>5. Запрещенные (disabled) и невидимые (hidden/invisible) поля не могут быть невалидными.
N>5. Нажатие кнопки ОК, в случае если не все поля валидны, выдает сообщение «Некоторые поля содержат некорректные значения».
N>6. Поле ввода даты — обычное текстовое поле, в которое можно вводить дату в нескольких форматах. Справа от поля находится квадратик с изображением календаря, при нажатии на него всплывает календарь с подсветкой выбранной и текущей дат.

N>До сих пор эта методика себя оправдывала. Использовались ее реализации под VB.NET/C#/VB6.

Методика хорошая, и, кстати, при написании приложений с Web-интерфесом тоже себя оправдывает Лет пять назад практически один в один для веба делал такую валидацию у себя на сайте (до сих пор там). Пример внизу сообщения...

Я бы добавил к вашему набору правил следующее:
1. В сообщении по кнопке OK можно выдавать список невалидных полей с указаниями, что нужно исправить. Если пользователю это не нужно — он просто проигнорирует текст и пойдёт сразу на форму исправлять ошибки. Если нужно — внимательно посмотрит и разберётся в чём дело.
2. Я не совсем понял, в какой момент у вас возникает тултип, но ИМХО лучше, если он возникает либо на mouseover, либо на setfocus на контрол. Иначе висящие тултипы могут загораживать часть других полей ввода. Кстати, по поводу информации в тултипе: при его всплывании, а не постоянном висении, в него можно поместить достаточно много информации, необходимой и достаточной для исправления некорректно введённых данных в этом конкретном контроле, вплоть до предоставления списка валидных значений и т.п.
3. Дату лучше вводить в формате текущей локали. Это универсальнее и однозначнее. Пользователи привыкают очень быстро. Кстати, для ввода даты можно использовать и маску (к сожалению на вебе сделать это получается довольно накладно). На вопрос "а что делать,если один пользователь русский, а второй — датчанин" ответ простой — датчанину — датскую локаль, русскому — русскую.
4. Использование масок отвергать не стоит. Например, при инсталляции Windows запрашивает код в 5 (!) полях ввода, вместо того, чтобы сделать одно поле с маской. Я частенько нехорошо выражался, когда делал ошибку в середине ввода и пытался клавигами вернуться в нужное место. А могло бы быть так легко... Мне кажется, что ввод по маске не удобен в том случае, когда они плохо реализован. Вот, например, в Delphi очень неплохой ввод по маске.
5. Ну и последнее — при поточном вводе тормозить пользователя и не пускать его на следующие контролы, если есть ошибки в редактируемом, ИМХО не очень хорошо, поскольку быстрые операторы вводят данные на автомате и торможение на одном контроле оператор замечает далеко не сразу. К тому же это сильно сбивает. Достаточно подсветки. Насколько я понимаю — у вас именно так предусмотрено поведение контрола при потере фокуса?

Кстати, не могли бы вы прояснить следующую фразу:

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

Имеется ввиду специальное место на форме, одновременно всплывающие тултипы или ещё что-то?

Пример вышеописанного к Web-интерфейсу (на цвет не обращайте внимания — так задумано ):

Здравствуйте, CiViLiS, Вы писали:

CVL>Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>>Здравствуйте, nzeemin, Вы писали:

N>>>1. Пользователь может вводить в поля все что хочет.

YKU>>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
CVL>Ненавижу MaskEdit Оснавная причина --- не возможно свободно редактировать поле: делать вставку из буффера, нельзя добавить новый символ, не удалив другой и т.д.

Вам попался плохой вариант ввода по маске... Хороший MaskEdit должен уметь нормально делать вставку из буфера, правильно размазывая вставляемое значение по маске, позволяет достаточно свободно редактировать поле и уж точно должен позволять делать Overwrite вместо Insert... Вот в Delphi компонент TMaskEdit всё это нормально умеет...

Здравствуйте, Spidola, Вы писали:

S>Здравствуйте, CiViLiS, Вы писали:

CVL>>Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>>>Здравствуйте, nzeemin, Вы писали:

N>>>>1. Пользователь может вводить в поля все что хочет.

YKU>>>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
CVL>>Ненавижу MaskEdit Оснавная причина --- не возможно свободно редактировать поле: делать вставку из буффера, нельзя добавить новый символ, не удалив другой и т.д.

S>Вот в Delphi компонент TMaskEdit всё это нормально умеет...
Вот он меня больше всего и раздражал. Хотя может со времен пятой дельфи что и изменилось. Я привык вводить все необходимые точки, запятые и прочее. Любое ограничение при вводе для меня зло. Хотя, если не сложно, сделайте и расшарте тестовый пример с различными типами ввода (дата, шестнадцатиричное число, вещественное число с ограничением дробной части и без, ввод числа из диапозона не кратного 10 и т.д.) Я попытаюсь найти случаии когда само редактирование поля может вызваться затруднения с моей стороны

ЗЫ Я за то, чтобы формат текста был в описании поля.
ЗЗЫ А где у нас Зверек, что то он молчит по этому поводу. Желаю знать мнение эксперта

Здравствуйте, CiViLiS, Вы писали:

O>>Не совсем понятен смысл делать кнопку ОК enabled, до тех пор, пока пользователь не введет все данные правильно.
CVL>На то есть пару причин. Первая -- неоправданная сложность кода --- необходимо обрабатывать сообщения об изменении полей пользователем, то есть нажатия enter, смену фокуса и пр...

Неверно. Для способа валидации, который я описал, достаточно ловить события изменения значений валидируемых полей (TextChanged или ValueChanged). Изменилось значение — пересчитывается валидация диалога. Нажатия Enter, смену фокуса — ловить совершенно не нужно.

CVL>ВО-вторых, иногда процесс проверки валидности поля очень длительный, например ввод хоста и проверки его доступности или какие нибудь сложные математические расчеты. Поэтому иногда удобнее делать валидацию только по нажатию кноки ОК.

Да, вопрос с длительной валидацией иногда возникает. В этом плане придерживаюсь правила: быстрая валидация (в том числе — зависимость полей) делается по изменениям значений, медленная валидация (а это обычно обращения к БД) — по нажатию ОК, и только после удачной проверки валидности быстрой валидации.

CVL>Есть еще один случай когда рантаймовскую валидацию использовать не следует. А имеено, когда диапазон вводимых значений зависит от значения введенного в другое поле. В этом случае, пользователь может увидеть знаки что все плохо, когда он еще не польностью ввел значения, что в свою очередь может пользователя заканфузить.

Не согласен. Когда возникает вопрос — "почему неверно?" — пользователь наводить мышь на поле, читает тултип и понимает в чем зависимость между полями. Сложные/неочевидные зависимости лучше еще описать в виде отдельного Label справа/снизу от поля.

Здравствуйте, Spidola, Вы писали:

S>1. В сообщении по кнопке OK можно выдавать список невалидных полей с указаниями, что нужно исправить. Если пользователю это не нужно — он просто проигнорирует текст и пойдёт сразу на форму исправлять ошибки. Если нужно — внимательно посмотрит и разберётся в чём дело.

Для этого нужно сопоставить всем полям их читабельные наименования. Если это не проблема — согласен, можно и так.
Как вариант — можно выдавать по ОК просто текст, где внятно описаны зависимости между полями в этом диалоге.

S>2. Я не совсем понял, в какой момент у вас возникает тултип, но ИМХО лучше, если он возникает либо на mouseover, либо на setfocus на контрол.
Это обычный tooltip, родной контрол Windows. Он возникает при наведении мышью на поле, исчезает сам через некоторое время.

S>3. Дату лучше вводить в формате текущей локали. Это универсальнее и однозначнее.
Полностью согласен. В каком-то ответе выше я уже говорил про даты...

S>4. Использование масок отвергать не стоит.
Использовать/не использовать маски — вопрос религиозный. Мне маски не нравятся в принципе, причины я вроде бы уже описывал...

S>5. Ну и последнее — при поточном вводе тормозить пользователя и не пускать его на следующие контролы, если есть ошибки в редактируемом, ИМХО не очень хорошо, поскольку быстрые операторы вводят данные на автомате и торможение на одном контроле оператор замечает далеко не сразу. К тому же это сильно сбивает. Достаточно подсветки. Насколько я понимаю — у вас именно так предусмотрено поведение контрола при потере фокуса?

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

S>Кстати, не могли бы вы прояснить следующую фразу:
S>

S>Валидация всего диалога описывается в одном единственном месте сразу для всех контролов диалога. Тем самым, всего в одном месте описываются как ограничения на отдельные поля, так и зависимости между ними.

S>Имеется ввиду специальное место на форме, одновременно всплывающие тултипы или ещё что-то?

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

S>Пример вышеописанного к Web-интерфейсу (на цвет не обращайте внимания — так задумано ):
S>
Ну... в общем, да — подход действительно близкий...

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>Что не слишком хорошо. К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате. ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.
Ну, на самом деле, вводить дату вполне удобно. Человек, привыкший к данному UI, набивает 7/5 почти с той же скоростью, что и 0705. Обрати внимание на то, что ведущие нули при таком вводе не нужны. Формат даты бывает разным только у плохо сломанных пиратских программ — в штатах, я тебя уверяю, обо всех этих вариантах и не слышали никогда. Для них просто 5 — это пятое число текущего месяца. 5/7 — это седьмое мая текущего года. 5/7/6 — это седьмое мая 2006. Все. Контрол должен это понимать — и все будет в порядке. Именно так ведет себя Excel.
Пользователь-новичок, скорее всего, вообще не будет пытаться тайпать в это поле. Он воспользуется календариком. И сразу же увидит, в каком формате привыкла представлять даты система.

Здравствуйте, yoriсk.kiev.ua, Вы писали:

YKU>К примеру, пользователь ввел дату, Ок, а лишь потом с удивлением(и матюками) узнает, что дату надо было вводить в другом формате.

Так в чем проблема — переведи дату в другой формат самостоятельно, т.е. программным путем. Я так и делаю.
Другой вариант — при получении фокуса ввода поле показвает подстказку о формате. Порльзователь не совсем дурак — может и прислушаться

YKU>ИМХО MaskEdit удобнее — сразу видно что от тебя хотят.

ИМХО, он действительно не очень удобен.