Keyboard wedge barcode readers have a long history in data entry in industrial settings.
One of my current Customers uses the UPC on the finished goods they make to "program" the PLC on their production line with the parameters of the finished good. The barcode reader is just "typing" the UPC and various commands into a serial-to-Ethernet gateway that's ultimately connected to a TELNET server on a PC w/ PLC software in it. Slick, if not a bit glue-and-tape (and kinda terrifying from a security perspective, albeit it is in a fairly well-isolated and filtered network segment).
I've seen an ERP system that printed command barcodes onto the paper "routers" accompanying physical parts around the shop. Workcenters scanned barcodes that "typed" the commands to drive the work-in-process job tracking into a PC running the client app. They used a prefix character as an attention sequence that could invoke menus then return the user back to the "screen" they were previously in. It was fun to type these on the keyboard directly.
I also supported a terrible application that used keyboard wedge barcode readers for "two factor authentication". Each user had a card with a code 128 barcode the vendor provided to scan as their "second factor". (The Customer showed the vendor how photocopies of the cards worked to "authenticate" after I pointed it out. The vendor replaced it with TOTP. It's all pointless because the app is based on shared-fike access to DBF files via a compiled Visual FoxPro application running on each client PC. I wish I was kidding. I also wish this application wasn't used for a very important and security-sensitive function, too... >sigh<)
There are doctors offices where you are supposed to present a confirmation or ID to a patient-facing barcode scanner at checkin. If you let it scan your code at the wrong time, at breaks the checkin flow. I can only assume that a mildly creative barcode could compromise all kinds of things.
One of my current Customers uses the UPC on the finished goods they make to "program" the PLC on their production line with the parameters of the finished good. The barcode reader is just "typing" the UPC and various commands into a serial-to-Ethernet gateway that's ultimately connected to a TELNET server on a PC w/ PLC software in it. Slick, if not a bit glue-and-tape (and kinda terrifying from a security perspective, albeit it is in a fairly well-isolated and filtered network segment).
I've seen an ERP system that printed command barcodes onto the paper "routers" accompanying physical parts around the shop. Workcenters scanned barcodes that "typed" the commands to drive the work-in-process job tracking into a PC running the client app. They used a prefix character as an attention sequence that could invoke menus then return the user back to the "screen" they were previously in. It was fun to type these on the keyboard directly.
I also supported a terrible application that used keyboard wedge barcode readers for "two factor authentication". Each user had a card with a code 128 barcode the vendor provided to scan as their "second factor". (The Customer showed the vendor how photocopies of the cards worked to "authenticate" after I pointed it out. The vendor replaced it with TOTP. It's all pointless because the app is based on shared-fike access to DBF files via a compiled Visual FoxPro application running on each client PC. I wish I was kidding. I also wish this application wasn't used for a very important and security-sensitive function, too... >sigh<)