Статья номера

Ненавязчивая валидация

ЯЗЫК: -
Автор: Никита Зимин,  ЖЖ Н.Зимина, полную версию читайте в №6 журнала "Алгоритм".

Проблема: диалоги и валидация

Диалоги, или точнее, диалоговые окна (dialog boxes), в настоящее время используются в интерфейсе большинства программ. С диалогами связана одна проблема, имеющая отношение к тому, что называют иностранным словом «юзабилити» (usability).

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

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

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

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

В-третьих, многие пользователи просто ненавидят сообщения об ошибках. Им не нравится, что машина указывает на ошибки человека.

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

Неудачное решение: ограничение ввода

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

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

Такой подход мне (как пользователю, если хотите) совершенно не нравится. Мне нравится, когда приложение в ненавязчивой форме само дает мне понять, как с ним работать, но при этом не держит меня в жестких рамках. Кроме того, ограничение ввода, по сути, «замалчивает» причину проблемы — вместо сообщения об ошибке пользователь теперь получает неприятный звук при нажатии «не той» клавиши. А это означает, что снижается самоописательность системы, и как следствие — возможность самообучения для пользователя.

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

Решение: ненавязчивая валидация

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

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

Что делать с кнопкой ОК?

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

«Быстрая» и «медленная» валидация

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

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

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

{К содержанию}

Время кода

Использование сетевых функций в C#

ЯЗЫК: C#
Автор статьи: DeveloperAdministrator , полную версию статьи читайте в №6 журнала "Алгоритм"

Вступление

Перед вами ещё одна статья из области «как я могу это сделать на Visual C#.NET». В этой статье будут обсуждаться сетевые функции библиотеки Win32 API. Первым делом нужно иметь представление о том, что управлять пользователями с помощью библиотеки .NET Framework мужно двумя способами. Первый использует Active Directory, однако, как вы понимаете, для этого нужно иметь установленный Active Directory. Второй используется в небольших сетях, в которых нет смысла устанавливать Active Directory – да его там никто и не ставит. В этой статье мы обсудим использование слоя Platform Invoke и сетевых функций управления пользователями библиотеки Win32 API. Мы увидим, каким образом можно добавить, удалить или изменить данные пользователя или группы пользователей на языке C#, а также каким образом мы сможем получить информацию о пользователе или машине в сети.

Приступим

Я думаю, многие разработчики, использующие C#, знают о том, что для доступа к функциям, находящимся в DLL, необходимо подключить дополнительное пространство имён:

using System.Runtime.InteropServices;

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

Добавление пользователя на языке C#

Одной из важнейших операций, которую можно осуществить с помощью сетевых функций, является добавление сетевого или локального пользователя. Для этого нам пригодится функция NetAddUser (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netmgmt/netmgmt/netuseradd.asp). Эта функция позволяет нам указать машину, на которой будет добавлен пользователь, или же можно указать null, если пользователь добавляется на локальной машине. В нижеприведенном фрагменте кода мы увидим, каким образом можно объявить и использовать функцию NetUserAdd. Нужно заметить, что информация о пользователе, который будет добавлен, должна храниться в специальной структуре. Эти структуры называются USER INFO 1. В этом примере мы будем использовать структуру USER_INFO_1 для определения данных пользователя.

В этом примере я не делаю обработку ошибок, так что, если возникнет необходимость, то вам придётся сделать её самостоятельно. Теперь у нас есть объявление функции API, осталось добавить структуру USER_INFO_1, а вот и она:

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

Итак, этот код добавит нового пользователя на текущей машине. Если же вы хотите добавить пользователя на другой машине, то нужно заменить первый параметр, установленный в null, на имя целевой машины. (Кроме того, для таких действий необходимо иметь соответствующие права – администратора или оператора учётных записей домена – прим. переводчика.)

Послесловие переводчика

Когда-то и я написал статью на эту же тему. Правда, в те далёкие времена (а это был 2001 год) я ещё писал на Borland Delphi, да ещё для журнала «Хакер», так что статья получилась достаточно специфическая. Называется она «LAN, WinAPI и другие», а прочитать вы можете её на сайте журнала - http://www.xakep.ru/post/14059/default.asp. 

Форумы .Net - вопросы оставшиеся без ответа

Batch обновления данных в БД по свойствам объектов
Вложенные курсоры Oracle из ADO.NET
ошибки при подключении к MS SQL
ADODB Connection переподключение после разрыва связи
как удалить куки
в каком событии в коде считать из HtmlInputHidden
Получение текущего значения DBWebGrid