Приведите пример метода FNSendItemBarcode для молока : Маркировка

ну так ведь:

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

Поэтому - пусть каждый для себя сам решает - нужна ли ему предварительная проверка структуры (и нужно ли её пытаться получить/проверить), а я лишь излагаю то, с чем сталкивался лично, и привожу аргументы для чего это может понадобиться.

Ну, ИМХО, это вообще за гранью...
Зачем? Есть же COM-порт, не важно, железный он, или эмуляция.
Там, таких проблем нет в принципе - что прилетело со сканера, то и передалось, и именно туда, куда нужно, и не зависимо от раскладки, регистра, "съедания" непечатных символов и прочих "особенностей" драйвера клавы...
Предвижу возражения - удаленка, сервер, на котором крутится приложение, а сканер на клиенте...
Так вот, опять-же ИМХО, проброс COM-порта по RDP, с клиента на сервер, делается намного проще, чем обход всех подводных камней подключения сканера в режиме эмуляции клавиатуры(по крайней мере, когда маркировка нужна). На любых Windows системах. За всякие линукс-подобные системы - говорить не могу, не работал с ними, но, тут похоже о них речь и не шла...

+ к предыдущему...

Есть конечно некоторое количество сканеров, которые нельзя переключить в режим COM... Это или заведомо с кабелем "в разрыв клавиатуры" PS/2, или совсем примитивные, дешманские китайские поделки... Но, в таком случае, тоже, дешевле их поменять на что-то более вменяемое, чем мучиться с костылями по обработке их "особенностей" в режиме KB... Даже, если их, когда-то пожадничав, некоторый "существенный" парк закупили.
Все нормальные сканеры, как брендовые - 100% так и непойми-какие китайцы 99%, имеют возможность перевода в режим эмуляции USB=>COM. Тот оставшийся 1%, проще выкинуть.

PS Мне попадались сканеры от "известного бренда", которые не удалось переключить в режим эмуляции СОМ, но, только под Win XP(у меня на многих кассах пока работают ХР, или эмбедеды на его основе, тяжелое наследство от ККС), но они-же встали на Win7-10 без малейших проблемм, как родные, даже без драйверов - со внутренними из винды...

Ну вот очень категорично. Я тоже придерживаюсь мнения, что лишние преобразования ни к чему. Но вот если у тебя sql запросы, в которых надо найти заданную марку, то тут придётся что-то предпринимать, так как в обычном виде не работает. Боятся преобразования не надо, так как это всего лишь фрагмент тип StringToHex или StringFromHex, которые везде есть (php, javascript и т.п.) или которые самому написать один раз работы на полчаса.

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

ага :) особенно если у тебя большая куча записей на выборку а ты еще и ф-ции навешиваешь, а потом сидишь и думаешь "а почему все так долго"- вроде простой запрос, а все как в 1с при переборе по циклу ...

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

я что то не понял
здесь нет преобразования
а здесь оно есть
ага, я тоже так наивно в далеком 97 думал пока на базу рофомса (тогда там тоже кларион был как у тебя сейчас, только еще родной) не натравил запрос с ф-цией а так как это была подработка то половину ночи на ожидание результатов ушло :)

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

Речь не касается клариона. На всякий случай, у него скорость работы сравнима с сишными программами, так как компилится в машинный код. Возможно, в 97 году у тебя был досовский кларион, который транслировался в байт код и уступал компилированным программам в 5-6 раз. Ну и от написания программы, оборудования скорость сильно зависит. Ты меня удивил про запрос в кларионе, который такое время мог крутиться.

У себя я храню без преобразования, так как скульные запросы не используются. Вопрос с преобразованием у меня возник, когда пришлось организовывать сервис проверки марок в сети магазинов. Он крутится на хостинге у провайдера, база данных sqlite. Так вот там пришлось преобразовать марки в hex. Я не знаю, есть ли другой вариант, с ходу не нашёл, а надо было поднять сервис быстро. Передача в запросе марки без преобразования не работало, движок sqlite спотыкался на спецсимволах.

ПыСы. Sqlite, скрипт на php.