Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Differentiate between input devices - VB.net

Status
Not open for further replies.

noonan59

Programmer
Oct 27, 2003
29
US
If I have 2 different input devices (such as a barcode reader and a keypad) connected via 2 USB ports, is there a way for a desktop application in VB.net to tell which device is inputting data at any given moment? Currently the program I am working on accepts the input from either device, but it doesn't know which device is producing the input. I need to have one set of code run if the input is from the barcode reader and another set of code run if the input is from the keypad.

thanks.... Dan
 
Can you post the code so I can see how you are getting the info?
 
Below is the code I have for the keypad. It's in the form's keydown event and it just saves each number the user presses until they press the enter key. As for the barcode reader I haven't done much with that yet because this is where my question is about recognizing it as the barcode reader instead of an input from the keypad. I tested the barcode reader in a textbox that had the focus and it does work, and it's just plug and play. I'm wondering if there is a way to recognize that an input is coming in from USB port 1 versus an input coming in from USB port 2. Thanks for your help.

''if user hits enter key on keypad
If e.KeyCode = Keys.Enter Then
''save data to SQL
Dim command As SqlCommand
Dim commandString As String
If gStudentId.Length = 6 Then
commandString = "INSERT into CafeTest values (@Acct);"
command = New SqlCommand(commandString, MyConnection)

command.Parameters.Add(New SqlParameter("@Acct", SqlDbType.Char))
command.Parameters("@Acct").Value = gStudentId

command.ExecuteNonQuery()
''clear global student ID for next entry
gStudentId = ""
End If
gStudentId = ""
Else ''pressing a number
If e.KeyCode = Keys.NumPad0 Then
gStudentId = gStudentId & "0"
ElseIf e.KeyCode = Keys.NumPad1 Then
gStudentId = gStudentId & "1"
ElseIf e.KeyCode = Keys.NumPad2 Then
gStudentId = gStudentId & "2"
ElseIf e.KeyCode = Keys.NumPad3 Then
gStudentId = gStudentId & "3"
ElseIf e.KeyCode = Keys.NumPad4 Then
gStudentId = gStudentId & "4"
ElseIf e.KeyCode = Keys.NumPad5 Then
gStudentId = gStudentId & "5"
ElseIf e.KeyCode = Keys.NumPad6 Then
gStudentId = gStudentId & "6"
ElseIf e.KeyCode = Keys.NumPad7 Then
gStudentId = gStudentId & "7"
ElseIf e.KeyCode = Keys.NumPad8 Then
gStudentId = gStudentId & "8"
ElseIf e.KeyCode = Keys.NumPad9 Then
gStudentId = gStudentId & "9"
End If

End If
 
It seems that you are getting in a pretty thorny area here. From what I can tell there is no way to this in VB.Net. I thought for sure there would be. It looks like you might have to move C++ to get low level control of the usb ports.

 
I thought that there should be a way to do it also, but I haven't come up with it either. thanks for your help.
 
The code will work the same whether it is input via keyboard or scanner.

I've got apps in production now that accepts input through either one of these devices.

Now if you're wanting to do something special.....



Scott
Programmer Analyst
<{{><
 
Basically what I have is users going through a cafeteria line and they will have the choice of using a keypad to input their id # or they can use their id badge to scan in their id #. While these id #'s are being entered, the cashier is using a touch screen and could be doing about anything with the program. The keypad works fine because the user presses an enter key that tells us they're finished. There is no enter button with the scanner, so I'm assuming we need to have some different code to handle when the user is finished scanning. That's where my question comes in about having the program understand whether the input was from the keypad or the scanner.
 
ok...you've got several options here..

1. Set the scanner to send an &quot;Enter&quot; command after the barcode is read.

1.1 Set the AcceptButton of the form to the button they would push if they chose to use the keypad. This activates when a user would press the enter key.
So when the scanner finishes reading and sends the &quot;Enter&quot; it will activate the click event of the button.
Check your scanner manual on setting the &quot;Enter&quot; command... I'm using this in my solutions.

1.2 Check the keypress and/or keydown events for the &quot;Enter&quot; command being sent by the scanner. When the &quot;Enter&quot; is captured, set off the click event of the button. ex. Button1_Click(New Object, New System.EventArgs)


2. I'll assume ID#'s are a specific length. Each time the keypress event happens check the length of the value in the textbox. If the length equals the number of characters then process the data....



did any of this make sense? If not post again and I'll confuse you some more






Scott
Programmer Analyst
<{{><
 
Thanks for the options - I'll check into them. The thing that concerns me is it will be possible for one user to be using the keypad to enter their id at the same time as another user is using the cardreader. This could cause a mixup with the 2 id's being entered at the same time. This is why I think I need two seperate pieces of code to handle each input device. So I'm back to square one as to how do I know where each input is coming from.

How's that for confusing!

thanks!
 
The thing that concerns me is it will be possible for one user to be using the keypad to enter their id at the same time as another user is using the cardreader.

yes... If the one person is keying something and someone else scans a barcode, then the data will be garbage.

This could cause a mixup with the 2 id's being entered at the same time. This is why I think I need two seperate pieces of code to handle each input device.

This is true, but when you do training make it clear that the person buying the food scans their card first before anything happens....

or

Make the cashier log into the system on your main form and store in a variable. This way you won't need to capture the cashiers id during each transaction. Just make sure you provide them with a way to log off




Scott
Programmer Analyst
<{{><
 
Here's the problem that I didn't mention - the users are a school full of kids that won't listen to anything! So we need to be able to handle their screw-ups! Actually the cashier does login. What were doing is putting the keypad and cardreader down the line a bit so the kids can enter their id, then the program goes to the database and gets the kid's name and places it in a list box so the cashier can just touch the kid's name when they get to cashier. So the listbox will usually have 3 or 4 names at a time.

I just realized that there is a way to recognize keypad vs. cardreader info. The keypad passes in keys.numpad1, numpad2, etc... while the cardreader passes in keys.D1, D2, etc...

I'm hoping you can help me with this: When using the cardreader the keypress and keydown events only seem to happen once so we're only capturing the first number of the id (with similar code as to the code above that I posted yesterday). How can we capture the entire id (7 digits)? We need to put this into a global and we can't use a textbox because the cashier could be doing anything when the id is entered by the cardreader, so a textbox can't have the focus.

gettin' kind of ugly isn't it?
 
Ok....i need to step back a think about this one.


What happens when a kid doesn't scan their badge or forgets it? How does the cashier handle this situation?

What are the possiblities of not trying to build queue of students? Just keep the scanner with the cashier and let the cashier scan the badge? What does having the kids scan gain you? Just thinking out loud.



Scott
Programmer Analyst
<{{><
 
The cashier has a way to search for the kid's last name via a keyboard on the screen.

You bring up very good points and I agree with all of them. However the person that has the final say wants to be able to build the queue of students. His feeling is it will move the line faster if the cashier already has the names up on the screen when each kid arrives at the register. And in fairness to him it probably will be a little faster. If we can't come up with a way to make all of this work together then we won't use the queue - or we will talk him into just using the keypad with the queue which we have tested and works fine.
 
well....we don't always get our way. ;-(

Here is the big issue, which I think you've identified. How to capture input from (N) devices that can be used at the same time.

The only easy solution I can think of is to have some other system present that is hooked up to the scanner. This system will capture the student ID's and place them somewhere, XML file, database, etc. Then your main app will refresh the list, based on the list, when a transaction occurs (ie.completes sale to a student)

Maybe I'm blowing this up but here it goes. When your getting input, a control will need to be active to capture the data. The problem is, no single control will always have focus because someone is using the interface.

If you are able to differentiate between keyboard and scanner inputs....how would you process the scanner inputs? No control will have focus to accept the data.

You could create an app that starts up with your main one, whose sole purpose is to capture data from the scanner.
This would probably need to be a service. The service would detect that traffic is coming from the USB port and then stick the data somewhere...then you would refresh the main app.

...again maybe I'm way off base but that's prolly how I would accomplish this under these requirements. Anyway, LMK what your final decision is.....I'm interested to know.


best wishes

Scott
Programmer Analyst
<{{><
 
Sounds like you have a good handle on our situation. That's a good idea about the separate app to control the scanner, and I think we will look into that.

thanks for your help. I'll let you know if we get this &quot;beast&quot; running!

-Dan
 
Well, since we talked last there has been a possible change in plans. There is talk now of just having the kids hand there cards to the cashier and to take the keypad out of the equation. The school administration all of the sudden is big on the card readers and not on the key pads. So basically we have stopped our work until they make up their minds 100% - gotta love it when nobody can make final decisions! So if they go with just the card readers that makes it real easy for us. I'll let you know if the pendulum shifts back the other way again.
 
not a good idea for a food service line, HEATH HAZARD, on kid gets a cold everyone in the line gets the cold.


if it is to be it's up to me
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top