08-17-2017 10:58 AM
You don't need all of the keyboard input functions. A string control in LabVIEW acts the same as Notepad. Use an event structure to capture the value changed event (which is triggered by the return character or end of line character). I do this all of the time and it works good for me.
See VI attached
08-17-2017 01:41 PM
@Joe_H wrote:
You don't need all of the keyboard input functions. A string control in LabVIEW acts the same as Notepad. Use an event structure to capture the value changed event (which is triggered by the return character or end of line character). I do this all of the time and it works good for me.
See VI attached
I believe this won't work. He stated earlier that the VI running won't have key focus.
Artem: Let me reword problem statement a bit... we can ignore the fact that this is a scanner at all. Really what you want to do is make a keystroke logger in LabVIEW - something that runs in the background quietly, detects "keyboard" input (scanner really, but you can't tell the difference), and records / processes it.
There is nothing in LabVIEW natively that I know of that'll do this. I haven't ever attempted it before, but I suspect you are going to end up registering for a callback system event. I'd start searching things like "Windows API capture keypress event" and the like.
08-17-2017 02:23 PM
My task really bigger. One app (not LabVIEW) controls the system, I can't change it. And this app take data from scanner. And I need second minimized app (LV). This one will check every code in DB. If code has flag "not tested", the second app must open warning window.
So you have one app that you want to have take data from the scanner that behaves like a keyboard, but you also want LabVIEW to take data from the scanner that acts like a keyboard?
That makes no sense! Have you ever seen multiple applications in Windows take data from a keyboard at the same time? Only which ever window as focus at the moment will capture the keystrokes coming from the keyboard.
08-17-2017 02:28 PM
08-18-2017 12:45 AM
Artem: Let me reword problem statement a bit... we can ignore the fact that this is a scanner at all. Really what you want to do is make a keystroke logger in LabVIEW - something that runs in the background quietly, detects "keyboard" input (scanner really, but you can't tell the difference), and records / processes it.
There is nothing in LabVIEW natively that I know of that'll do this. I haven't ever attempted it before, but I suspect you are going to end up registering for a callback system event. I'd start searching things like "Windows API capture keypress event" and the like.
Problem: there is an engraving machine. He has a code scanner. On the screen, the buttons: "start" and "stop". No keyboard or mouse.
The worker scans the code and presses "start". The machine engraves the code on the product.
We want to be sure that the product has been tested, otherwise we do not need to engrave the code. We can not change the program of the system, but we can run a parallel application that will read the data in parallel and check them in the database.
08-18-2017 12:55 AM
RavensFan wrote:
That makes no sense! Have you ever seen multiple applications in Windows take data from a keyboard at the same time? Only which ever window as focus at the moment will capture the keystrokes coming from the keyboard.
It works, but not correctly.
On my 1st screenshot notepad and vi works simultaneously, but VI get incorrect data.
I thougt the Acquire Input Data VI will return me only new data from buffer, but look like it return all data in buffer.
08-18-2017 09:03 AM
How do you enforce the user to NOT press start?
Can you block the start of the other program? Or is it up to the user, to wait on your program NOT to come with a pop-up, before he/she presses start?
How long time should the user wait for that?
Are you sure that he/she will not press start with the scanned bar code?
In what language is the other program made?
08-18-2017 06:02 PM
An alternative way to handle this might be to connect a barcode scanner via virtual serial (rather than virtual keyboard wedge), read it via VISA into your LabVIEW application, do whatever data validation/database lookup you've described, and then, only if it passes the validation, send keystroke data (using the WinAPI SendInput() function in user32.dll) for the engraving application to process. If the "Go" or "Start" control on that application supports a keyboard shortcut, you could even generate that keystroke, so the entire process could be hands-off.
Just a thought.
Dave
08-19-2017 06:12 AM
dkfire asks the Key Question -- how do you prevent the User from pressing Start after the Scan? Do you have control of the Display? Do you interact in any way with the Engraving Machine?
One of my applications uses a Bar Code scanner to select specific items for a test. We know which items go to which Test Station. The user selects an Item, scans it, the program says "Place in Test Station <whatever>" or "No, we are not testing that item".
So if you want to use your scanned information to "make a decision", you need to interact with the Operator in some way.
If all you want to do is skip the Engraving, would returning an empty string do the trick? Would that prevent an engraving, and would the operator notice and remove that (presumably faulty) device?
Bob Schor
08-19-2017 01:54 PM
If the code is correct, the program keep silent.
If the product is not tested, the program opens a warning message.
The operator himself decides whether to continue engraving, or not.