» Обработка неверно введеного значения

Здравствуйте. Хочется услышать ваше мнения и советов по следующему вопросу.

Исходная ситуация. Есть элемент ввода. Пусть вводимое значение должно удовлетворять какому-то условию. Вопрос собственно в том, что делать, если введеное значение условию не удовлетворяет. В коллективе мнения разделились.

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

Мнение два: сообщать пользователю об ошибке, но позволять покинуть поле ввода (естественно с невозможностью все таки в дальнейшем записать неверное значение в БД).

Хотелось бы услышать, кто как решает данный момент.

venoel
С точки зрения эргономики (минимум телодвижений пользователя в дальнейшем) надо запретить редактровать другие поля, пока это заполнено неправильно. НО, необходимо в любом случае перед записью в базу проверять корректность данных, так как мышой можно проигнорировать несколько контролов и в итоге будет ошибка. Как вариант кстати проверку корректности записи повесить на триггер в самой БД и в случае ошибок делать rollback transaction с ошибкой.
Объясню почему я склоняюсь в сторону запрета редактирования других записей, пока есть ошибка в текущей. При больших объемах почти все пользуются клавиатурой только и возвращаться чтобы отредактировать ошибку - это трата лишнего времени - один фиг пока не будет все ок, сохранить не удастся.

2) +1
+ выдача сообщения с детальным описанием проблемы.

то что проверка должны быть и перед записью в БД - это само собой разумеется. Интересует именно "поведение" программы: позволять или нет покинуть фокус поля ввода, в котором неверное значение (пусть временно). О запись в БД плохого значения - и речи нет.

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

ymg2000
+1
как-нибудь подсвечивать неверное значение при смене фокуса и сообщение обо всех замеченных ошибках при попытке сохранить данные.

ymg2000
Да, именно так и стараюсь делать. Осталось убедить в этом подчиненных.

Цитата:

А ты бы хотел заполнить другие поля и затем вернуться к проблемному. Позтому я бы смену фокуса разрешил, но заведомо неправильное значение подкрасил другим цветом.

Т.е. предлогается прверять значение ВСЕХ полей по крайней мере 2 раза? Раз на смену фокуса, второй на запсь. А зачем? Ну не хотите/не можете ввести правильное значени, очистите контрол и продолжайте.

dneprcomp
Если во главу угла ставить пользователя, то и проверяй и подкрашивай, и не забывай про "защиту от дураков". Если считать, что пользователь(заказчик) не только всегда прав, но и до "непотребности" умен, то можно оставить пользователю возможность "обнулять" контролы. Он непременно догадается, что его нужно очистить, а не нажать Exit или т.п.

ymg2000

Цитата:

Он непременно догадается

Так на то мы и девелоперы, а не кодеры, что бы непремено догадался. И именно так как надо.
Проверять надо. Но зачем же множество раз? Раз происходит ненужная повторяющаяся работа, значит дизайн программы не додуман.

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

ymg2000
"Для себя" обсуждению не подлежит.

Цитата:

становится вопрос удобной и комфортной работы для пользователя

Не только пользователя. Существует еще и предприятие. И вот для него важнее правильность введенных данных. По иерархии это стоит выше удобства.
Локание фокуса как раз и является "защитой от дурака" в процессе сохранения данных.
Какой смысел водить остальное, если данное поле несоответствует?

dneprcomp
Мы здесь не обсуждаем очевидное: необходимость проверки данных перед записью в БД. Напомню, обсуждается несколько другое:
Цитата:

Есть элемент ввода. Пусть вводимое значение должно удовлетворять какому-то условию. Вопрос собственно в том, что делать, если введеное значение условию не удовлетворяет.

Я еще раз повторюсь: интерфейс ввода д.б. максимально дружелюбен пользователю (если тебе нравится, пользователю - представителю предприятия). Для меня это также очевидно, как и проверка вводимой информации. И если логика ввода позволяет не ограничивать пользователя при заполнении им полей, эту возможность ему нужно давать. В данном случае под "не ограничевать" не понимается "не проверять".

ymg2000

Цитата:

И если логика ввода позволяет не ограничивать пользователя при заполнении им полей, эту возможность ему нужно давать. В данном случае под "не ограничевать" не понимается "не проверять".

Не понимаю, что общего у "не ограничевать" и "проверять". Если существуют критерии ввода, то прверять и ограничивать. Если же
"не ограничевать", то критериев ввода по просту нет.
При потере фокуса уже произведена проверка на валидность. Не вижу необходимости повторно что-либо проверять при записи в базу.
Или проверяем сразу в контроле, или потом при записи в базу.
Повторюсь, какой смысел в двойной проверке?

PS. Похоже< что мы рассуждаем о разных уравнях проверок. Я говорю не о проверке на уровне "ввели цифру - должна быть буква" ; "ввели букву - дожен быть год". При потере фокуса осуществляется полная проверка на валидность даных с точки зрения структуры базы. Таким образом, если, скажем, поле ввода 'День рождения' содержит в себе 949 вместо 1949, то какой смысел продолжать ввод без исправления?

dneprcomp
Цитата:

Таким образом, если, скажем, поле ввода 'День рождения' содержит в себе 949 вместо 1949, то какой смысел продолжать ввод без исправления?

Никакого. Поэтому при смене фокуса поле с 949 помечается как ошибочное (например, подсвечивается другим цветом), и прользователь может внести коррективы сразу либо вернуться к этому полю позже. При попытке же записать в БД с ошибкой обычная реакция системы - откат транзакции, сообщение об ошибке и установка курсора на поле с ошибочными данными.

На мой взгляд, всё зависит от контекста. Например, предназначена форма для быстрого ввода или для редко выполняемх действий.

В целом пользователям больше нравится, когда программа делает то, что он хочет - при нажатии Enter или стрелочки переместит курсор, а не будет ругаться. Лучше всего, если рядом с полем в этом случае будет краткое описание того, что сделано неправильно. Пользователь, увидев это, нажмёт стрелку в обратном направлении и повторит ввод. Либо бегло заполнит несколько полей, и окинет взглядом, что получилось неправильно. Либо попытается зафиксировать данные - вот тут уж придётся переместить курсор и вызвать Exception. Думается, до отката тразакций в этом случае дело не должно доходить. Проверка на сервере - последний рубеж обороны.

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

ymg2000

Цитата:

При попытке же записать в БД с ошибкой обычная реакция системы - откат транзакции, сообщение об ошибке и установка курсора на поле с ошибочными данными.

откат транзакции не происходит, т.к. не нужен. В базу ничего не пишем, т.к. изначально имеем ошибку. Остальное - "сообщение об ошибке и установка курсора на поле с ошибочными данными" - ходьба по кругу Т.к. пользователь может игнорировать (уйти с контрола!!!) при любой ошибке. Практически тоже самое, что и с вариантом локанья контрола. Толька размер круга рзный
По прежнему не могу понять чем же так удобнее ходьба по большому кругу, чем по малому. Все равно пользователь обязан исправить. Ну так пусть сразу исправит и дело с концом.
Если пользователь не может исправить сейчас, он и позже не сумеет. Тогда какой смысел для него водить все даные на форме, если записи не произойдет из-за ошибки в поле? Чем скорее пользователь осознает необходимост исправления или прекращения ввода, тем меньше времени потратится в пустyю на ненужный ввод.

dneprcomp
Транзакция да, это последняя инстанция...
А по-поводу хождения по кругу, тут как раз я даю пользователю возможность либо повторно попытаться ввести валидные данные в проблемное поле, либо заполнить другие поля и лишь затем вернуться к нему. Я даю определенную свободу действий пользователю - на его усмотрение. Сможет пользователь корректно ввести (исправить) данные сразу или сможет это сделать чуть позже, мы не знаем. Но зачем же его жестко ограничивать. Например, если он не может сразу правильно ввести почтовый индекс, то почему бы ему не дать возможность сначала ввести название города, улицы и т.д., а потом вернуться к вводу индекса?

ymg2000

Цитата:

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

Ну не может, и на здоровье. Пусть не вводит. Ничего вообще в это поле. А если он туда абракадабру ввел, то зачем она там нужна? Пусть уберет и идет себе дальше. Програме все равно придется его заставить вернутся и исправить. Так зачем же метаться по форме и по логике кода, делать проверки по нескольку раз...

Народ смысл ругаться из-за такой мелочи. Добавьте в настройки программы чекбокс типа
"При некорректном вводе не блокировать, а подсвечивать". И пусть юзверь сам решает что ему лучше.

ShIvADeSt
Да мы не ругаемся. Мы вяло обсуждаем логику проверок...

PS. А чекбокс по дефолту должен локать
PPS. Не-а. Чекбокс не пойдет. Все равно придется две проверки делать. Лишнеe - ненужное.

Цитата:

Добавьте в настройки программы чекбокс типа
"При некорректном вводе не блокировать, а подсвечивать". И пусть юзверь сам решает что ему лучше.

Это вполне приемпемо, хороший вариант...
dneprcomp
Как понимаю, мы не придем к единому мнению. Поэтому остаемся каждый при своем. Иначе обсуждать будем до бесконечности...

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

Т.е. исходить нужно от задачи, а не от собственного (субьективного) понимания правильности или неправильности подхода.

afiget

Цитата:

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

Ээээ наоборот, слепой ввод подразумевает наоборот постоянно видеть форму, а не клавиатуру.

Цитата:

Ээээ наоборот, слепой ввод подразумевает наоборот постоянно видеть форму, а не клавиатуру.

Не путать слепой ввод (документов, мы ведь об этом речь вели) и слепой набор!

Пример слепого ввода: формирование документов по заранее сформированным заявкам (как напечатанным, так и написанным от руки) у оптовиков.

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

Qraizer
Ну так это и есть специфика для данного вида ввода.

To All
А вообще действительно, каждому виду ввода свою обработку.

dneprcomp

Цитата:

А вообще действительно, каждому виду ввода свою обработку.

Это стопроцентно.
...А что мы тогда обсуждали...?

ymg2000, неприемлимость крайностей.

Qraizer

Цитата:

неприемлимость крайностей.

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