Почему при сканировании штрихкода на ТСД через RDP не срабатывает внешнее событие в 1С?

Программист 1С v8.3 (Обычные формы) 1С:Управление торговлей Торговля и дистрибуция
← На главную

При автоматизации складских операций с использованием терминалов сбора данных (ТСД), работающих в терминальной сессии (RDP), нередко возникает плавающая ошибка: при считывании штрихкода процедура ВнешнееСобытие не вызывается. Вместо этого символы штрихкода попадают в активный элемент интерфейса как обычный клавиатурный ввод. Если в этот момент курсор находится в табличной части на числовой колонке, платформа 1С активизирует механизм быстрого поиска, открывая окно ввода символов. После этого дальнейшее сканирование блокируется до тех пор, пока оператор вручную не закроет режим поиска.

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

Причины сбоя: почему клавиатурный ввод не превращается во внешнее событие

Для понимания корня проблемы проанализируем, как работает сканер в режиме клавиатурного клина (Keyboard Wedge / КБД) внутри сессии RDP:

  1. Разрыв пакетов и сетевые задержки (RDP latency): Драйвер торгового оборудования на стороне сервера перехватывает символы с помощью низкоуровневых клавиатурных хуков (WH_KEYBOARD или WH_KEYBOARD_LL). Если штрихкод передается без явных аппаратных префиксов, драйвер определяет начало сканирования по скорости поступления символов (интервал между нажатиями). При сетевых всплесках Wi-Fi пакетизация протокола RDP нарушается, символы приходят пачками с неравномерными интервалами. Если пауза между первым и вторым символом превышает установленный порог, драйвер считает первый знак ручным вводом пользователя и пропускает его в операционную систему.
  2. Сброс клавиатурного хука операционной системой: В ОС Windows существует параметр LowLevelHooksTimeout. Если терминальный сервер кратковременно перегружен или обработчик хука не успевает ответить системе в отведенный тайм-аут, Windows автоматически отключает данный хук или пропускает необработанные нажатия напрямую в окно с фокусом.
  3. Захват фокуса окном быстрого поиска: Как только первая цифра штрихкода попадает в колонку таблицы, 1С открывает встроенный диалог быстрого поиска. Этот элемент захватывает клавиатурный фокус на уровне низкоуровневых окон Windows, блокируя последующую генерацию внешних событий до сброса поиска клавишей Esc или клика мыши.

Способ 1. Перевод сканера в режим виртуального COM-порта (Virtual COM)

Перевод сканера ТСД из режима эмуляции клавиатуры в режим виртуального COM-порта — наиболее надежное архитектурное решение. В этом случае поток данных вообще не использует клавиатурный буфер Windows и не зависит от текущего фокуса элементов формы 1С.

  1. В системной утилите настройки сканирования на ТСД (DataWedge, ScanService или аналогичной) переключаем режим вывода данных (Output Mode) с Keystroke / Keyboard Wedge на Serial / Virtual COM.
  2. В настройках RDP-клиента на ТСД активируем проброс последовательных портов (COM-портов) в терминальную сессию.
  3. В 1С подключаем сканер как стандартное торговое оборудование через порт (например, COM3).
  4. При таком подключении считанная последовательность байтов напрямую обрабатывается драйвером сканера и гарантированно вызывает процедуру ВнешнееСобытие с параметрами события.

Способ 2. Настройка аппаратных префиксов и суффиксов сканера

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

  1. В утилите сканирования ТСД добавляем к передаваемым данным обязательный префикс (например, символ STX с кодом 02 или специальную клавишу вроде F12) и суффикс (символ перевода каретки CR или код 13).
  2. Открываем форму настройки драйвера торгового оборудования в 1С.
  3. В параметрах подключения сканера явно указываем добавленный префикс и суффикс.
  4. После такой настройки драйвер игнорирует временные интервалы между символами: он ожидает поступления жестко заданного стартового символа. Символы не передаются в активное поле формы, пока не поступит завершающий суффикс, что полностью устраняет проблему ложного срабатывания поиска в таблицах.

Способ 3. Корректировка чувствительности драйвера и тайм-аута хуков Windows

Если используется драйвер с распознаванием по скорости ввода, необходимо настроить чувствительность (порог срабатывания) под особенности RDP-соединения:

  1. В параметрах драйвера увеличиваем допустимый интервал между символами (порог чувствительности) со стандартных 30–50 мс до 100–150 мс, чтобы сетевые задержки RDP не приводили к дроблению штрихкода.
  2. На сервере терминалов корректируем значение системного тайм-аута для клавиатурных перехватчиков. В ветке реестра: HKEY_CURRENT_USER\Control Panel\Desktop проверяем или создаем строковый/DWORD параметр LowLevelHooksTimeout и устанавливаем значение 5000 (время ожидания в миллисекундах), чтобы предотвратить принудительное отключение хуков операционной системой.

Способ 4. Обновление драйверов и переход на технологию NativeApi

Устаревшие внешние компоненты, разработанные по технологии COM, подвержены конфликтам в многопользовательской среде терминального сервера. Рекомендуется обновить компоненты интеграции:

  1. Переходим на актуальные версии драйверов из состава Библиотеки подключаемого оборудования (БПО), использующие стандарт NativeApi.
  2. Компоненты NativeApi выполняются непосредственно в адресном пространстве платформы без дополнительных прослоек взаимодействия и обеспечивают корректную доставку событий в сессиях удаленного рабочего стола.
  3. Проверяем, что в конфигурации для обработки входящих данных используется типовой механизм:
    
    Процедура ОбработкаВнешнегоСобытия(Источник, Событие, Данные)
        
        Если Источник = "СканерШтрихкода" ИЛИ Событие = "Штрихкод" Тогда
            ОбработатьШтрихкод(Данные);
        КонецЕсли;
    
    КонецПроцедуры
    

Способ 5. Альтернативная архитектура: сокеты или мобильный клиент

При регулярных проблемах с RDP-сессиями на мобильных устройствах стоит рассмотреть изменение архитектуры взаимодействия:

  1. Передача через TCP/IP-сокет: На ТСД сканер настраивается на отправку данных по протоколу TCP на определенный порт сервера, где вспомогательная служба перенаправляет поток в порт конкретной терминальной сессии.
  2. Использование мобильного клиента 1С: Переход с RDP на нативное приложение или мобильный клиент 1С на операционной системе ТСД (Android). В этом случае сканирование считывается через системные широковещательные намерения (Broadcast Intent) штатными средствами мобильной платформы, что полностью исключает влияние клавиатурных фокусов, сетевых пингов и интерфейсных окон поиска.
← На главную