I'm dealing with a barcode scanner that acts as a keyboard emulation.
I print my barcode labels with a custom heading character (pipe) .
In my main form, I listen to the keypress event and as soon as I see the custom header character, I start receiving the scan and than do my stuffs.
This method works pretty well if my application is focused but can't do nothing if the application is minimized or unfocused.
I tried to setup a keyboard hotkey. It partialli works: my application get focused on the first character but is not fast enought to capture the subsequent characters spitted very fast from the scanner.
Any idea on how to capture this keystrokes with the application unfocused?
Obviously if the heading char id detected the subsequent characters must be suppressed until the sequence is completed with a vbcr or a timeout is reached.
Note that the scanner spits a sequence of 15 characters in less than a tenth of a second
This is how Windows works, only the active application will handle keyboard input. Thus, when your application is minimized, it will not receive or handle any keyboard input.
As Bradley Uffner commented, you need a global keyboard handler, I've used this in the past and it works quite well. Basically a system wide listener that will handle keyboard input even while minimized.
Related
Background:
I'm writing a fuzzy-finding vim plugin which runs a graphical program as a separate process. It opens a window, you type into it, press return, and then the vim plugin processes its output and navigates to the file / buffer you selected.
The time between triggering the find function and the new process grabbing keyboard input is a fraction of a second, so it's possible to accidentally type too soon, which causes that input to be delivered to vim.
Given that vim is single-threaded, I know (and have verified) that the errant keyboard input is not actually processed until the program finishes - the input is buffered while the program runs, and afterwards the random keys I typed are interpreted as vim actions.
Question:
How can I discard input that's sitting in vim's input buffer but has not yet been processed?
inputsave() takes pending keyboard input and saves it onto a stack. This would be what I want, except that it causes a memory leak if I don't match it with a call to inputrestore(). Is it possible to discard the stored input without executing it?
If that's not directly possible, can anyone think of a good way to discharge those events into a safe place? i.e call inputrestore() in such a state that the stored input will have no visible effect.
I need to do this in both a normal-mode mapping, and a command-mode mapping. So I'd prefer a solution which doesn't abandon the current command-mode input.
I have a Windows Application in VB.NET. I want to know if a value is entered by a user via the keyboard, or if it is coming from a barcode reader. I want to store values that come from
the keyboard in a different database than the ones the come from the barcode reader.
Option 1:
Get a barcode-scanner that is connected to a serial-port (raw serial device read by a COM port). As most barcode-scanners emulate keyboard strokes there is no way to directly distinguish a barcode scanner input from a keyboard input (see next option) without going low-level (see last update).
One connected to a serial port (or emulated one via USB as serial-ports are not so common anymore) gives you full control on where the input comes from.
Option 2:
Count number of chars typed by time. Barcode-scanners inject a sequence (line) pretty fast compared to typing. Measuring the time used in the textbox by counting key-presses (use CR+LF as a measure point as these are sent by the scanner as well) can give you one method to distinguish if a human is typing (unless there is one typing fast as f) or the content was injected. If timed-out just reject/clear the input.
In addition the checksum of the barcode (if you use one that contains that) can be used to do an extra validation in addition to time measurement.
(you can detect pasting by overriding the ctrl + v as in the next option).
Option 3:
Combine option 2 but instead of measure in the textbox tap into the ProcessCmdKey() function (by overriding it) and measure there if textbox has focus. This way you can first buffer input, measure time and if within a set time-out value, inject the line into the textbox.
Option 4:
This might be a good option as well:
http://nicholas.piasecki.name/blog/2009/02/distinguishing-barcode-scanners-from-the-keyboard-in-winforms/
Option 5: a non-technical approach -
Usability improvements: make it visually very clear that bar-codes must be entered with a scanner and not typed. I am including as an option as it is simple and if made correct also effective (there's no right answer of what is correct unfortunately).
Approached could include f.ex. a watermark in the textbox ("Don't type, scan!" or something in that order). Give it a different color, border, size etc. to distinguish it from normal textboxes, and have a help text associated and available at all time that improves clarity.
i know my question seems very similar to others according to a buffer-clear issue... but here is a detailed description:
I have an motorolla handheld (bar-code scanner) which is reading barcodes over an tray tool.
The code is scanned by the traytool und is casted as an keystroke like a normal press on a key on a keyboard.
so i have an app in vb which should read a barcode and after that a second and than proceed the inputs.
after reading 12 chars/numbers my textfield should set the focus to an other textfield (2. barcode) so i check onChange the length and than set the focus to the next textfield.
if there is a malicous barcode or a barcode which contains more than 12 characters/numbers the second textfield will be filled with all chars after the 12. char from textfield 1.
i have no control over the scan behaviour or the keydown event of the scanner trigger... nothing possible.
also there is no termination symbol in the input data which signals me that one block is ending here.
so how is it possible to clear the buffer of the virtual keyboard of the scanner ?!
any suggestions?
I suggest downloading the manual for your scanner to find the configuration codes. They are typically a set of special barcodes that can be scanned to set properties such as allowed symbologies. What you will want to do is set the scanner so that it appends a CRLF, Tab, or other terminator for your data. That way you can act upon the end of the barcode.
You can use TWAIN to handle the scanning thought i am not sure whether it supports Motorola. Try to download some TWAIN libraries and in-cooperate them with your project.
I have a USB bar code scanner that is acting as an HID keyboard emulation device. I want a web page that, for testing purposes, pops up a JavaScript alert when a scan is done. I don't want to tie the event to any visible control such as a textbox so thus, I won't have focus on any control to capture the scan input. Can this be done? I'm using VS 2010 with .NET 4.0 and VB.NET with a Symbol USB bar code scanner. Thanks ... Bob
Different bar code scanners can output different control characters like tab and line feeds. You should read the manual for your scanner.
You should be able to pick those up with a key press event handler.
During development i have observed that certain PDAs with Windows CE and possibly Windows Mobile too are sending the Enter key twice in the key pressed event thus i execute twice the code that lies under the control's key press event for the return button.
I suspect that this is a hardware bug and i would like to ask how you resolved it without changing your application logic.
Without changing the logic? You really can't (unless there is a hardware or firmware fix). I'd guess the simplest mechanism (that requires a logic change) is to treat two Enter keys or keypresses in a short period (say < 100ms) then ignore the second.
I don’t know if this will help but if you read the keyboard port Enter is seen as two bytes rather than one.
This happened to me too and it turned out it was because the "enable character repeat" option was enabled in control panel->keyboard. The default repeat delay was way too fast for the keypad that we used, so I just slowed it down and the problem went away.