How do I lock out the keyboard?

[lmtis]

We just strip off the @ symbol before it gets to the display.

Jim

[ShawnB]

I was kinda thinking along these lines already as a backup.  Our barcodes already have some extra characters built in, like +E27 or +H15.  These don't show up in the printed numbers under the barcode, so a person wouldn't know to type them.  Knowing our workforce, however, it wouldn't take long for someone to figure out (i.e. one of the Engineers shows them) how to type in these numbers manually.  The solution needs to be more permanent...

[lmtis]

Permanent as in to cut off said engineers fingers?

[ShawnB]

If only.... >:-)

[Matthew_Kelton]

Well, there is the Windows API call BlockInput which will disable the mouse and keyboard until you turn it off or the user hist Ctrl-Alt-Del.  I have used it in the past when I had to do some 3rd party application automation and didn't want the user the mess up the keyboard or mouse events necessary to automate it.

Now, you haven't really said what type of scanner you have.  If it is a PS/2 type, this will also disable the scanner, as it is treated as keyboard input.  If you have a serial or USB scanner, this may do the trick.

Here is the info on the API call:  http://msdn2.microsoft.com/en-us/library/ms646290.aspx.

Another option you could consider if you can't find another option is a hardware lock.  If you have a PS/2 keyboard, you can put a black box in line before the scanner which is just a series of relays to disconnect the keyboard from the PC.  There would be no keystroke backdoor to this one, though.

Of course, if you want to have the backdoor, you're still going to have that pesky engineer showing them how to turn off the disable function.  Heck, I was in a situation once where they had taken the keyboard away.  I went over to another PC and stole its keyboard.  They will get around anything you put in place if they have to.

The simple truth is if they want to get around it, they will.  I think your best solution is the prepend characters with the scanner (especially an ESC sequence), and filter out all other traffic.

What is the reason they do not want to use the scanner?  I would think they would prefer it since it should be faster and easier.  I haven't foudn too many test technicians which prefer the method which requires more effort.

[ShawnB]

Thanks for the thoughtful response, Matt. 

Of the roughly 100 various programming stations we have on the floor, some use PS/2 scanners and others use USB.  I believe the plan is to phase out the PS/2 scanners, but until then any solution will obviously have to deal with both styles.

The black box idea is a good one, but cost factor and time implementing would prevent it from being accepted by management.

You know, it's a really good question for why they don't want to use the scanner.  Their chief complaint is that the plastic bag that they have to scan through sometime prevents the scanner from working properly.  But still, it may only take an extra second or two to flatten out the plastic and get the scan.  OR, they could just take the scan page out of the bag and keep it out until a particular order is complete.  I honestly don't understand the psychology behind their protest, and I honestly don't care.  Short of firing all of them (not going to happen) I have to find an effective way of enforcing the scanner rule. 

If I were to use BlockInput, how do I call that from labview?

[Matthew_Kelton]

Here is the VI I use (in 7.1)

[pincpanter]

Hello Shawn,
I would suggest another approach for your problem: although the keyboard and the barcode scanner are indistinguishable by the program, certainly the speed of the character input is much different in the two cases and can be detected.
Check the attached vi; when the mean time/char exceeds a threshold, the string is cleared: the user is always allowed to input one character, but every subsequent input would be destructive. Increasing the threshold would allow to input the whole string. Of course, the value of the threshold should be tuned to allow actual input from the scanner. Please note that the Update value while typing option must be on for the string control in order to manage every single keystroke.
If we would know for sure that a scanner reading would generate only one Value Change event, the code could be even simpler: in the string Value Change event, clear the string if OldVal is not empty.
The vi also discards CTRL+V events and forbids run-time short-cut menus in the vi properties (Window appearance), because this kind of input is very fast and could be used as a workaround.
Hope this helps.

[lmtis]

Paolo,

That, my friend is a 6 star reply.  The VI is broken, but the solution is elegant.  S~

Jim

[parthabe]

Matt,

Can I simply go ahead disconnecting the typedef from its .ctl ?

Anyhow it has only one instance in the set of VIs you ve posted.

Great work, indeed!