We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now

x

card swipe/bar code pen capture?

Foyal
Foyal asked
on
Medium Priority
587 Views
Last Modified: 2008-02-01
How can I capture the input from a card swipe/bar code pen which connects with a keyboard passthru so that I can send it to an application which does not neccessarily have the focus. I need to be able to keep the thing monitored at all times and not interfere with keyboard input meant for other active applications. Any help on this will be greatly appreciated.
Comment
Watch Question

zsi

Commented:
The manufactureer of the scanning device will have provided a driver.  When information is scanned in, whatever visual control on the screen has the focus will receive the input (if it is capable of receiving input).

The device simply emulates the keyboard.  Depending on the brand of scanner that you have, you should be able to program to the interface so that your application can receive notification and have to opportuinity to bypass the information.

However, intercepting an arbitrary device is probably not possible. For security reasons, I am sure you can understand why a manufacturer might not let you do this.  Also, I don't know of any windows message that might get broadcast during the scanning process.  

Author

Commented:
Since this will not work for the application as required I had to reject ZSI's answer... In order to perform the function described in my question, will it be neccessary for me to use a different type of scanner (serial port) and then poll the port constantly in order to make sure my app can recieve any input from the scanner while allowing keyboard input meant for other active apps? If this is true, can someone direct me to a source example for such a thing?
zsi

Commented:
Why not use an OCX control that communicates with a scanner?

Author

Commented:
zsi-
That still leaves the problem of being able to intercept scanner input and use it in this particular app while allowing other active applications to have the user's focus for keyboard or mouse input.
Foyal
Foyal,

You have a scanner with a keyboard wedge?  (Out of curiosity, what brand is it?)
If so, all it does is allow your scanner to "pretend" it's the keyboard. Typically, it's possible to configure the wedge to send a header or trailer character, so you can identify (programmatically) the difference between scanned & keyed input.

However, unless you write code to monitor the keyboard buffer and intercept scanned data before it gets to the active control, the scanned data will go to the active app.

Why is this your design?  Is this a POS app?  if so, does it make sense for your scanning to be totally modeless?  (i.e., i can understand allowing a scan at any point while your app is running.  in that case, just (!) code all relevant controls to look for the header char, grab the data until the trailer char, and send the data to the relevant routine.) would your user, for instance, scan while in netscape, let's say?

Author

Commented:
Staplehead-
The reason for having this app continuously receive any input from the scanner is that is will be remotely located in order to track personnel entry (similar to a time clock). If the machine on which the program is running should be used by someone at its location for any other purpose (like internet access, email, calculator, etc), then my app should still be able to work in the background (minimized). I would very much like to keep the scanning part from being proprietary as far as the scanner hardware is concerned, although this may not prove to be possible. Intercepting all user input and filtering it for scanner input may be the best answer. Do you know if all scanner hardware has the functionality to add the special characters you mentioned? If not, could you specify some brand which does? The original hardware I mentioned (with the keyboard passthrough) does not have a manufacturer name on it anywhere, just a large sticker which says W-WEDGE and a S/N: Y50115012953. If this sounds familiar, let me know who you think the manufacturer may be so I can contact them.
Thanks,
Foyal
Foyal,

When I was doing barcode work, I used Compsee wedges.  Can't say much about other brands, since it was a company decision made before I was there.  here's a URL for ya:
       http://www.tennecom.com/barcode/compsee/genwed.htm

i noticed that they talk about the kinds of output chars you can embed.  instead of making your app look for all keyboard input, maybe you could activate it on a certain key combination; as long as the wedge can send it out (and why shouldn't it be able to?!), you'd be set.  (caveat: i haven't done this sort of thing in VB, and offhand, don't have any implementation detail advice; if you don't have Appelman's API book or the hardcore VB book, i could take a look in them for ya).

i'd think, though, that this is a better approach thaan attempting to trap _all_ keyboard input.

keep something in mind, though: throw a keyboard wedge into the mix, and that's yet another piece of hardware to control.  they _do_ go down, or "lose" their programming occasionally (frequency depends on the environment, how "gentle" your users are, etc.).  it will _not_ be a support-free installation, but hopefully, not support-intensive...

Author

Commented:
Staplehead-
Thanks for the info. I will check out the url you posted.
See ya
Foyal
Commented:
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION
kfrick:

your answer is right: setting the app to use a serial port *is* easier on the coder... you hardcode which serial port you want, and away you go!

only problem is, you better hope that your user never wants to use that com port, or doesn't attach the wedge to the wrong port ("well, this plug is 9-pin, and that port is 9-pin" !!!).

i agree, though: in a perfect world, the more control the developer has on the user's hardware, the easier; if you can't ensure that level of control, wedging into the keyboard is more "standard", fwiw !

Foyal:

in any case, an ounce of prevention is worth _hours_ of, well, troubleshooting.  don't allow your wedge to autodiscriminate if you're only using one symbology; better yet, since barcodes exist on (relatively) perishable media, go magstrip if at all possible or within budget.  remind your client that perishables costs tend to outstrip initial implementation costs in the long run: CYA with the _most_ _solid_ design you can get them to sign off with up front.  also, since you're dealing with peripherals, decide what's the maximum failure rate you're willing to guarantee, and do some sort of data collection & reporting; that way, when (not if) the system fails during run-time down the line, you can run your metrics and say, "sorry! can you say 'T&M'???"  ;^)

            Larry

Author

Commented:
kfrick and staplehead-
Thanks to both of you for your help on this question. I think I am going to with the serial port solution. Should be receiving the new hardware to begin testing in a day or two.
Thanks Again...
Foyal
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.