I am working on reading the barcode using a scanner and I have the following questions:
Is there a way to distinguish between the input from the keyboard and input from the scanner ? This is required for me because the barcode reader will include a preamble, terminator and a prefix to the barcode value. For ex, if the value is 12345 the barcode will have \pre12345\ where \ and \ indicate the start and end and pre identifies the type of data.
If I know that the data is being typed from keyboard and not from a scanner then I would show whatever the user types.
If I know that the data is from a scanner then I will strip of the \pre and \ and show only the data.
Thanks,
My answer assumes that you are using a barcode scanner in "keyboard wedge" mode where it simply emulates a keyboard and does not have some special connection. These devices are often USB and work this way out of the box without any further configuration.
Would the user ever have occasion to actually type your \pre text? Often the prefix is chosen specifically to be a set of characters that the user will never enter or will at least very rarely want to enter. Thus, the mere presence of the prefix indicates a scanned barcode.
Another option would be to time the input. For example, the input from the barcode scanner will probably all be complete within a very short time (e.g. 50ms). If a user were typing the value via the keyboard, it would be impossible for him/her to type the prefix, the data and the postfix all within 50ms. (Of course, assumption here is that input will be made by an actual human and not by automated tools)
well yes! input from the barcode scanner should have first initialized itself through a COM port or serial connection. I know that many apps restrict input to certain field through specific ports, but beyond that I'm not sure.
One solution that I came up with was to start all of our barcodes with a unique sequence of characters not known to the user. I check for this sequence on the input to tell me how the data was entered.
Related
I have a question related to this topic: New line in Zebra ZPL. I want to print a serial number, which is longer than the label. There shouldn't be a hyphen in this seral number.
It is printed by a PLC, which gets the format as ZPL from a PC. I get the ZPL file only, if the format changes. The data which have to be printed on the label will be given as variables.
I can't change the communication configuration (e.g. connect the printer directly to the PLC or change the program in the PC). This means, I can't split the serial number into two lines (like I did in another project). But, of course, I can change the PLC program, but it must be changeable to new formats without changing the PLC program again. So from my point of view, splitting the code in the PLC program is not an option.
Until now, I only had to possibility to change the code, to have automatic word wrap with a hyphen or split the serial number into two lines.
Hopefully someone has a suggestion.
With kind regards,
Alexander Härtel
Use the ^FB command (field box).
The first argument is the width in dots (always in dots, this is the only command that ignores ^CU units of measurement (which is an undocumented fact)), the second argument is the maximum number of lines the box can have. (There are other arguments too.)
^FO100,350
^FB100,2
^FD1234567890^FS
Labelary example.
I am writing a small shell in Rust on Linux as an exercise and I wanted to implement command history as well as cursor moving (i.e. moving back the cursor to edit a typo in the command).
I did not find a way in the Rust standard library to handle arrow key events, but I found the Termion crate which handles key events.
However, handling key events with Termion means entering "raw mode" for stdout, which overrides "legacy" functionalities, as described in this article about the crate:
Without raw mode, you cannot write a proper interactive TTY application. Raw mode gives you complete control over the TTY:
It disables the line buffering: As you might notice, your command-line application tends to behave like the command-line. The programs will first get the input when the user types \n. Raw mode makes the program get the input after every key stroke.
It disables displaying the input: Without raw mode, the things you type appear on the screen, making it insufficient for most interactive TTY applications, where keys can represent controls and not textual input.
It disables canonicalization of the output: For example, \n represents “go one cell down” not “break the line”, for line breaks \n\r is needed.
It disables scrolling.
I find this solution a bit overkill, as I want to retain most of the "legacy" I/O functionalities. Is there another way to handle arrow key input, or will I need to use the raw mode?
There are several crates that provide line editing features for interactive programs. Here are a few that I found by searching crates.io for "readline" (the name of a C library):
rustyline seems to be the most popular on crates.io.
liner
linefeed
linenoise-rust is a set of Rust bindings to the linenoise library written in C.
I haven't used any of them, so this list is not a recommendation. Take a look at a few of them and choose one that suits your needs.
Is it possible to automatically detect the escape sequence for a key combination?
, i.e., instead of running cat followed by pressing ctrl+right or ctrl+left manually to detect the escape sequence as ^[[5C or ^[[5D respectively, can it be automated? In that case, we may be able to send fn(ctrl+left) or fn(ctrl+right) as input to cat via pipe and get the output(for the first time, when ^[[5C or ^[[5D are unknown) directly.
fn(char a[]='ctrl+right') {..outputs the actual keypress signal for the input string a.. ;} | cat; fn=?
This question is the exact reverse of my other question https://stackoverflow.com/questions/34547008/reverse-map-the-keys-binding-value-to-the-key-combination.
I am asking this to automate the process of setting up key-bindings in the terminals, for devs, so that they need not run manually for all possible combinations, as we had to do now (as seen here)
Is it possible to automatically detect the escape sequence for a key
combination?
Since the shell (as any user program) has no insight into the terminal driver, it cannot predict what the driver will do with a key combination. Consider also that with certain terminals we can change the keyboard's behavior (e. g. cf. xmodmap). Automatic detection is not universally possible.
I am trying to create an application which reads IDs of blood samples via a barcode reader. How do I read a barcode from a barcode reader into a Java Application for further processing (e.g pulling patient details from database)? Example code and explanations much appreciated.
P.S same applies to fingerprint reader, also need to be able to pull data from database based on usb fingerprint reader. how do I get fingerprint reader data into the java application for further processing?
Thanks in advance,
Tumaini
It really depends on the hardware you are using (i.e. The Barcode scanner) most scanners simulate keyboard input and will for example write a string of numbers + a termination character.
e.g. 1 2 9 7 6 5 [ENTER]
If your hardware does simmilar you will be able to trap this as text input in Java - no specialist coding needed.
A simple way to test what your hardware does is open up a text editor, scan a barcode - then view the output on the screen (with special characters included)
I have to set up a system for an online-pass generator using barcodes.
The module i developed lets the admins set which codes are available, and when a user requests a pass, the php script generates a jpeg of the pass with a small barcode print at the bottom.
The barcode is generated using:
http://www.dafont.com/3of9-barcode.font
Q: Are those barcodes universal? I need to know if the barcode scanner will work on those printed passes.
There are actually quite a few different sets of barcode characters out there. You need to find out which standard the scanners that will be reading the codes will use and find a font or generator that supports that standard.
See http://en.wikipedia.org/wiki/Barcode#Symbologies for a list of them.
mikeschuld has provided good information about barcode printing and scanning. My experience has been that Code 39 is one of the most pervasive barcode formats and every scanner that I have run into has been configured to read Code 39 barcodes by default.