Hello,
I would appreciate some help putting a stream of numbers from a USB magnetic card reader into a variable.

I have a USB Magnetic Card Reader (type MSR210). When I swipe any magnetic card it returns a stream of numbers. No matter what program is opened (Excel, Notepad, or even a command prompt) it puts that stream of numbers in the opened program and ends the stream with a return (CR).

I would like to have my form1.vb being aware of a magnetic card being swiped. (without that stream being put into any field that has current focus at the time, e.g. a textbox.)

I want to pick up the stream of numbers, put it into a variable then extract form the variable a number that is identifying our club members (userid) and use that to set the bindingmanager index to a userid in the database (the program will then show user data and picture of that member).

Questions: how do I:
1. Pick up the stream of numbers from the USB port (if that is what I must do - to eventually put that number into a variable)

2. If not 1. then how do I capture the stream of numbers at any time (no matter what object has focus on the form)

3. How do I make sure the stream of numbers is ONLY entered into my variable and not into a field that has current focus?

Thank you in advance for your help.

- Tsadok

You'll need to refer to the device manual further I think.

It sounds like what is happening is that the device is simply "typing" the values it gets from the card. So it is essentially acting as a user interface device like a keyboard. If you have a windows form application active you can capture keyboard input and put the values somewhere else (i.e. your "card number" variable). The problem here is that if this is the way the device does indeed behave you may very well not be able to distinguish between characters entered by the device and characters entered by the user at a keyboard. So the program would similarly consume the characters entered by a user because it can't tell the difference. This will require you to have the focus on a specific control such as a textbox so that the device can enter the data.

Does the device provide any additional data that might help you identify input from it versus that from a keyboard (perhaps some prefix characters to what is scanned)?

One possible solution could be pattern recognition. Your form could watch what is being "entered" (by either the user or the device) and then look for the pattern of the numbers you would expect from the card reader. When you encounter input that matches, you could perform the necessary action. If the user happens to have focus on an input field such as a textbox, you could erase the number you just recognized from that textbox so it would be as if it wasn't entered.

Looking at this from the perspective of usability I wonder if it wouldn't be sensible to set this up as a textbox entry field anyway. What happens if the card reader can't read the card? Shouldn't the user be allowed to manually enter the card number that's printed on it? This could remove the problem of trying to hide the reader input from the user while providing the user with a fall back in the event of a problem.

-Peter

[quote]Originally posted by planoie
 You'll need to refer to the device manual further I think.

First - Thank you Peter for your quick reply.
The device doesn't come with a manual and you are right - the USB Card reader is listed in Windows Hardware as HID Keyboard.

When a card is swipped a long row of numbers (15-19 characters) starting with 000 appears. That would indeed make it possible to distinguish them from other input BUT... I would rather pick-up the stream from the HID Device using a capture or such.

I have browsed the endless solutions on MSDN and Google about HID-Classes and RawInput API's see e.g. http://msdn2.microsoft.com/en-us/library/ms996387.aspx but I seem not to comprehend the how to capture the data originating from the HID Keyboard (Card Reader).

- Tsadok

I would guess that there is Windows message traffic associated with this action.

As you probably know, everything that happens in Windows is message based. When you press a key, a message is generated, when you release it, a message is generated. When you move the mouse messages are generated.

It seems reasonable that when this reader starts talking, there is message traffic associated with that. You can cause a VB program to pay attention to messages through the API functions Windows comes with. Research messaging, and how to add message handling to your app.

After adding message listening, log activity while using the reader, and see if you can discover the specific messages that this device raises. Then you'll be able to refine your “listening” process so as to handle input from this device in the way that you need to.

Like I said, just guessing.

  Thank you BrianWren. You must have expected the next question:
Being a newbie and not at all familiar with debugging yet...
Question:

Please point me to any documentation about activating "listeners" in VB2005. I have Rod Stephens book (VB 2005 Programmers Reference) but cannot find anything about streams originating from HID, and other ports other then a serial port.

Thank you all again in advance for taking the time to help me.

- TSadok

Well, I wasn't using a technical term... What I would do if I were you, is research using APIs (this involves adding a statement that starts with "Declare Sub . . . " or "Declare Function . . . ") and using Windows Messages.

As for a "listener," what I meant by that was having a process in your app that pays attention to messages.

Perhaps I'll come back in a bit and add some more.

I believe the API that is going to helpful for this is GetMessage()

Hi There,

I know its been a while, but I have a MSR152 that I am trying to get data out of and don't quite know where to start... how did you setup the initial communication and what commands were you sending to get at the stream of numbers? Documentation on these things is unbelievably scarce considering how many of them must be out there!! Any help greatly appreciated!

Cheers

Mike

As I understood from this thread, the device acts like a keyboard.

So you would write your program to get set for keyboard input, then, when the screen shows the input box you've prgrammed, or the textbox, then you would sent the card through.

The problem in this thread, was that Tsadok didn't want to set the program to listen, then give it the input, he wanted to be able to have the insertion of a card bring the program around to the listening state in time to actually capture the stream coming from the reader.

Does that help?