Исчезает окно предупреждения.

← →
kyn66 © (2009-08-20 10:50) [0]

Добрый день мастера. В своей программе по сканированию(сканер штрихкода) билетов лотерей пытаюсь выдать предупреждающее сообщение в случае повторного сканирования одного и того-же билета. Выполняю это за счет промежуточных таблиц, в которых сохраняю успешые данные о билете. Однако окно предупреждения быстро мелькнет и не появляется. В чем может быть дело?
... procedure ErrorMsg(st : String); begin Application.MessageBox(PChar(st), "ОШИБКА !", MB_OK + MB_ICONHAND); end; ... else if(DM1.TiragSLTbl.FindKey([StrToInt(SerLab), Nomlab + IndLab])) then if not TirMemTbl.Locate("Tir;Bilet", VarArrayOf([StrToInt(SerLab), Nomlab + "." + IndLab]), []) then begin TirMemTbl.InsertRecord(["", StrToInt(SerLab), Nomlab + "." + IndLab, Dm1.TiragSLTblWinSum.Value]); StaticText3.Caption := Razrad(DM1.TiragSLTblWinSum.AsString); Image1.Picture.Bitmap := PicClip1.GraphicCell[0]; end else begin ErrorMsg("Повторное сканирование билета !"); Edit1.SetFocus; Edit1.SelectAll; Exit; end;

← →
Медвежонок Пятачок © (2009-08-20 10:54) [1]

дело может быть в сетфокусе

← →
kyn66 © (2009-08-20 10:55) [2]

Дополню, что в среде Delphi в режиме отладки ,пошагово, окно появляется нормально. Складывается впечатление, что что-то нажимает автоматом кнопку Ok

← →
kyn66 © (2009-08-20 10:56) [3]

> дело может быть в сетфокусе

Edit1.SetFocus;
Edit1.SelectAll;

Отключал, не помогло...

← →
sniknik © (2009-08-20 11:17) [4]

> быстро мелькнет и не появляется.
> что что-то нажимает автоматом кнопку Ok
сканер. у него часто либо постфиксом либо сам он умеет энтер в конце штрих кода посылать, проверь, считай в мемо, будет переход на следующую строку после кода.
надо чистить "буфер клавиатуры" после чтения со сканера, если тебе это не нужно.

← →
Медвежонок Пятачок © (2009-08-20 11:24) [5]

а из какого потока идет вызов бокса?

← →
kyn66 © (2009-08-20 12:05) [6]

Да, сканер Enter возвращает. Но иногда приходится работать и на таком, который не возвращает. У меня их два для тестирования проги. А каким способом лучше очистить буфер клавиатуры? Я в примере нашел(Delphi Word), но он выдает ошибку
procedure EmptyKeyQueue; var Msg: TMsg; begin while PeekMessage(Msg, 0, WM_KEYFIRST, WM_KEYLAST, PM_REMOVE or PM_NOYIELD) do; end;

← →
Kolan © (2009-08-20 12:35) [7]

А что плохого в повторном сканировании билета?

← →
Медвежонок Пятачок © (2009-08-20 12:40) [8]

плохое здесь на самом деле - это необходимость давить на кнопку мессджбокса держа в руках сканер

← →
Kolan © (2009-08-20 12:44) [9]

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

← →
kyn66 © (2009-08-20 12:46) [10]

> А что плохого в повторном сканировании билета?

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

Проверил, да действительно виноват сканер. Сейчас подключил старый, не возвращающий Enter. С ним все пучком, предупреждение появляется. С новым сканером проблема осталась даже после
begin EmptyKeyQueue; ErrorMsg("Повторное сканирование билета !"); Edit1.SetFocus; Edit1.SelectAll; Exit; end;

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

← →
Медвежонок Пятачок © (2009-08-20 12:48) [11]

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

← →
kyn66 © (2009-08-20 12:48) [12]

> Мне тоже кажется, что всплывающего полупрозрачного не мешающего
> работн сообщения будет достаточно.

Оно не полупрозрачное, а невидимое впринципе. Оно появляется и тут-же закрывается само, практически незаметно для глаза. А окно это - информационное и должно выполнять свое назначение прямое.

← →
Медвежонок Пятачок © (2009-08-20 12:50) [13]

эргономика тогда ни к черту.

← →
kyn66 © (2009-08-20 12:54) [14]

> эргономика тогда ни к черту

Не понял.... Это к чему?

← →
Медвежонок Пятачок © (2009-08-20 12:56) [15]

это будет программа для трехруких мутантов.
в одной руке билет, во второй сканер, третья - наготове нажать баттон если билет уже был

← →
Kolan © (2009-08-20 13:01) [16]

Автор, прочтите, пожалуйста, раздел 5.2.3. Экранные состояния объектов:

http://raskin-interface.narod.ru/interface/chapter5.htm

← →
kyn66 © (2009-08-20 13:03) [17]

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

← →
Kolan © (2009-08-20 13:06) [18]

Может, kyn66, у пользователя и хватит рук, но есть еще и ментальные ограничения.

← →
Andy BitOff © (2009-08-20 13:13) [19]

> kyn66 © (20.08.09 12:54) [14]
> > эргономика тогда ни к черту
> Не понял.... Это к чему?

Это к тому, что оператору по барабану какой это билет, это тебе не по барабану.
За сим, достаточно будет или в StaticText3.Caption вывести красным, мол, ля-ля-ля, или же в Image1.Picture.Bitmap загрузить подготовленный заранее желтый восклицательный знак в красном кружочке.
Не надо заставлять юзера выполнять не нужные телодвижения. У тебя же не критичный вопрос с возможностью выбора, а просто информация.

← →
kyn66 © (2009-08-20 13:14) [20]

> Автор, прочтите, пожалуйста, раздел 5.2.3. Экранные состояния
> объектов:

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

← →
Медвежонок Пятачок © (2009-08-20 13:15) [21]

дабы выпустить из руки уже ранее проверенный билет. Психология, однако... ;)

Он его и так выпустит причем в обеих случаях. Тем более что их у него пачка

← →
Медвежонок Пятачок © (2009-08-20 13:16) [22]

это примерно как в обоих ветках ифа вываливать сообщение "алгоритм пойдет на север" и "алгоритм пойдет на юг"

← →
kyn66 © (2009-08-20 13:17) [23]

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

Согласен, есть в этом здравый смысл.

← →
Andy BitOff © (2009-08-20 13:18) [24]

> kyn66 © (20.08.09 13:14) [20]
> Когда речь идет о 500 и более билетах

А какое процентное соотношение повторов?

← →
Kolan © (2009-08-20 13:19) [25]

Мне сценарий представляется таким:
о Оператор сует билет второй раз.

о Возникает полупрозрачное окно, где крупно написано Повторное сканирование билета! (заметьте, восклицательный знак не отрывается от слова). Полезно было бы пикнуть при этом динамиком.

о Пока оператор берет другой билет окно исчезает.

← →
Медвежонок Пятачок © (2009-08-20 13:19) [26]

А какое процентное соотношение повторов?

это сильно зависит от открытости окна и силы ветра на улице.

← →
Andy BitOff © (2009-08-20 13:21) [27]

> kyn66 © (20.08.09 13:17) [23]
> Согласен, есть в этом здравый смысл.

Еще бы ты не был согласен =))))

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

← →
kyn66 © (2009-08-20 13:38) [28]

Сделаю я наверное обычный всплывающий PopUp справа снизу в стиле аля-ХР и этого будет достаточно. Я думаю внимание будет привлечено.

← →
Kolan © (2009-08-20 13:53) [29]

Мне кажется звук очень важен.

Дело в том, что когда человек выполняет монотонную работу он быстро научается выполнять её автоматически.

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

Например можно идти, жевать жвачку и болтать по телефону при этом ходьба и жевание будут автоматическими.

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

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

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

← →
Andy BitOff © (2009-08-20 14:04) [30]

> Kolan © (20.08.09 13:53) [29]

Несомненно поддерживаю.

← →
Дмитрий Белькевич (2009-08-20 14:43) [31]

> Полезно было бы пикнуть при этом динамиком.

+1.

> http://raskin-interface.narod.ru/interface/chapter5.htm

Книга - уг.

← →
kyn66 © (2009-08-20 14:50) [32]

2Kolan

Согласен на все 100%

← →
kyn66 © (2009-08-20 14:53) [33]

Только со звуком опять же могут возникнуть проблемы. Если просто через Beep, то зависит подключен динамик к компу или нет, громкий он или тихий и т.д. Задействовать звуковую карту - тоже проблема еще та. У кого она есть, у кого нету, у кого есть , но звук выключен и т.д.

← →
Kolan © (2009-08-20 15:05) [34]

Разве трудно проиграть вавку каким-нибудь TMediaPlayer?

Хотя думаю, что бип лучше. Динамики есть на многих машинах.

← →
Amoeba © (2009-08-20 15:20) [35]

> Хотя думаю, что бип лучше. Динамики есть на многих машинах.

И выдать его не однократно, а дважды или даже трижды.

← →
sniknik © (2009-08-20 15:33) [36]

> проблема осталась даже после
> begin
> EmptyKeyQueue;
> ErrorMsg("Повторное сканирование билета !");
> Edit1.SetFocus;
> Edit1.SelectAll;
> Exit;
> end;
проверь уж все
begin
Application.ProcessMessages;
EmptyKeyQueue;
Sleep(0);
ErrorMsg("Повторное сканирование билета !");
...
можно в разных комбинациях.

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

← →
sniknik © (2009-08-20 15:38) [37]

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

← →
Kolan © (2009-08-20 15:39) [38]

Amoeba, со звуками в этом плане почти так же как с цветами. Есть целая теория. Причем сам по себе звук, как и цвет ничего не значит, а вот металлический лязг в машине на скорости 150 км/ч вполне вероятно насторожит водителя :)

← →
Andy BitOff © (2009-08-20 15:42) [39]

> sniknik © (20.08.09 15:38) [37]

Дык про это ему и втолковывают ;)

← →
Kolan © (2009-08-20 15:50) [40]

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

← →
kyn66 © (2009-08-20 16:20) [41]

> а если невнимательный товарищ "просканит" штрихкод уже при
> "поднятом" окне сообщений?

Сканер не сработает, т.к. в данный момент потеряет фокус элемент Edit1, на свойстве onChange и происходит обработка полученного значения по штрихкоду

← →
kyn66 © (2009-08-20 16:23) [42]

> проверь уж все begin Application.ProcessMessages;
> EmptyKeyQueue; Sleep(0); ErrorMsg("Повторное сканирование
> билета !");...можно в разных комбинациях.

Неа, не работает, проверил

> [31] Дмитрий Белькевич (20.08.09 14:43)

определение "уг" в студию.

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

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

> В техническом плане мне вообще кажется, что обработка получения
> кода окнами неверная.

О как. Я раньше как-то долго и упорно спрашивал у народа, каким образом обработать полученные данные со сканера, как их впринципе получить. Сканер обычный, ручной. Через Tedit или ему подобные в основном обработка и происходит и не только у меня. Только в отличие от других программя я еще предусмотрел и контроль за потерей фокуса компонентом TEdit, который получает данные от сканера.

> Сканер не сработает, т.к. в данный момент потеряет фокус элемент Edit1
как сканер узнает про фокус Edit1-а? вот сейчас про "прицепленный" ентер не узнаёт, а про цифры/и ентер от следующего скана узнает... какая избирательность...
(да если бы у тебя так было, то нынешней проблемы бы не было)

> А данные по билету не запишутся
ну и о чем тогда сыр бор? или создается специальный механизм сообщений чтобы пользователей раздражать?

Model-View-Controller (MVC) неплохо работает, советую ознакомится с этим архитектурным решением. Получение кода в TEdit полностью противоречит MVC отсюда и большинство проблем.

> как сканер узнает про фокус Edit1-а?

Никак , я за это отвечаю. Сканер как выполнял свою прямую работу так и продолжает...

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

> kyn66 (20.08.2009 16:26:44) [44]

Тогда нафига какие то диалоги, окна,звуки - очень ненадишь пользователей?

> Тогда нафига какие то диалоги, окна,звуки

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

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

> Kolan (21.08.2009 10:45:52) [52]

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

О факте аннулирования нужно обязательно уведомлять. Иначе, по простому, будет: «я сую сую, а оно не работает», а по умному: из-за отсутствия обратной связи человеку будет трудно понять на каком уровне произошла ошибка.

Да никакой ошибки не приозошло, опять же по словам автора.

> Да никакой ошибки не приозошло, опять же по словам автора.

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

> kyn66 © (25.08.09 16:10) [56]

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

А чего это сразу и "необдуманными"?
Может ему текст, цвет или звук предупреждения понравился.

--
Regards, LVT.

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

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

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

> sniknik © (25.08.09 21:49) [58]

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

Понятно, что гнать-то изначально надо юзера.
Хотя, и таких дизайнеров и прочих кульманов.

--
Rergards, LVT.

> вообще, если кассир/юзер настолько туп, что не с состоянии
> понять "тревожный" писк значит

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

Исчезает окно предупреждения. Найти похожие ветки