Использование сканнера штрихкода как клин клавиатуры подразумевают, что Вы не можете подтвердить получение сканирования?
У меня есть чрезвычайно простое приложение, убегающее серия сканеров устаревших, которая берет сканирование штрихкода от последовательного порта и передает обратно сканеру хорошо, что он получил сканирование. На основе этого сканер высвечивается зеленый, и пользователь знает, что они могут продолжить.
Мне нравится эта модель по моему пониманию клина клавиатуры, потому что, если что-то происходит с приложением, берущим сканирование (приложение зависает, форма с фокусом изменяется, ПК зависает, ПК не может продолжить взятие сканирований), человек, держащий оружие сканирования, будет знать, что существует проблема, потому что они не получат зеленую флэш-память, и они не смогут продолжить сканировать.
Я смотрю на добавление некоторых сканеров, и кажется, что многие люди используют сканнеры штрихкода, которые эффективно действуют как клинья клавиатуры. Некоторые из этих сканеров имеют диапазоны, которые превышают 100 футов, подразумевающие люди используют их далеко от ПК (как мои пользователи). Таким образом, я задаюсь вопросом, отсутствую ли я, что-то относительно клавиатуры втискивает модель. Есть ли некоторый механизм, который я пропускаю, чтобы гарантировать, что сканирование, декодируемое сканером, действующим как клин клавиатуры на самом деле, достигает приложения, работающего на ПК? Полноценный карманный компьютер, выполняющий что-то как Windows Mobile, походит на крупное излишество для того, чтобы просто желать гарантировать, что мой пользователь не сканирует данные, которые не входят в приложение и так делают даже средний сканер с клавиатурой и экранируют, но действительно ли последний является точкой входа для какого-либо вида programmatibility сканера?
2 ответа
Вы правы - нет обратной связи со сканером, когда он работает как клин. Мы часто используем сканеры клина, и в современной среде (например, Windows, несколько приложений и т. Д.) Фокусировка, «пропущенные сканирование» и т. Д. - все это реальные проблемы.
Мы находимся в процессе перехода на другой путь. Если у вас есть выбор оборудования, многие новые USB-сканеры штрих-кода могут работать в режиме последовательной эмуляции, который обеспечивает тот же тип взаимодействия, который вы описываете (где вы можете предотвратить второе сканирование, пока хост не подтвердит первое, или вы можете подать сигнал / прошить что-нибудь на сканере как ACK). Также там' sa USB HID POS (POS-режим), который поддерживают некоторые USB-сканеры более высокого класса, что дает вам еще большую гибкость, с дополнительным бонусом в виде установки «без драйверов» (он выглядит как обычное HID-устройство для системы, как джойстик или клавиатура, но с возможностью двусторонней связи). Обратной стороной режима POS является то, что он немного сложнее последовательного программирования, но существуют уровни абстракции, доступные для разных платформ.
Мобильные радиокомпьютеры со встроенными сканерами, такие как символ MC9090-G, на сегодняшний день являются самыми гибкими, и мы используем их больше всего. Что касается клиньев, в зависимости от расстояния до ПК и заводской среды - мы использовали визуальную обратную связь через экран ПК и аудио - через динамики ПК. Пользователи слушают аудио обратную связь после каждого сканирования, а когда они ее не слышат, они оглядываются на экран ПК для получения визуальной обратной связи о проблеме. Не идеально, но это сработало хорошо
.