Foyal
asked on
card swipe/bar code pen capture?
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.
ASKER
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?
Why not use an OCX control that communicates with a scanner?
ASKER
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
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?
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?
ASKER
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
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...
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...
ASKER
Staplehead-
Thanks for the info. I will check out the url you posted.
See ya
Foyal
Thanks for the info. I will check out the url you posted.
See ya
Foyal
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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
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
ASKER
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
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
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.