09-07-2005 03:17 AM
09-07-2005 05:44 AM
You can read keyboard clicks without using a string control, but it won't be as simple as a serial read.
First, you can use the VIs in the Advanced>>Input Device palette, which will tell you which button is clicked at any moment. This means you will have to continuously poll and that you could, theoritically, miss some keys.
Second, if you want to capture keystrokes inside the VI, you can use an event structure with the Key Down event. This will gurantee that you get all the clicks and you don't need to poll.
Third, you can probably call some windows API functions to intercept the windows event which is fired when you press a key. Try searching the Microsoft Developer Network (MSDN), which has documentation of the windows API.
09-15-2005 05:32 AM
Thanks - and sorry I've been a bit late to respond.
Maybe a combination of your first two suggestions could do the job, but it looks like a fair bit of carefull programming would be required to get the right behaviour.
For the time being, I think I'll have to stay with reading from a string control.
Regards.
Mark H.
09-15-2005 06:17 AM
There is no need to combine the first two methods.
If your VI is the active window (it will be if you use the string control), then the second method (key down event for the VI) is all that you need, and it will work perfectly.
The third option is probably more complex, but may be possible. You can try doing some reading here to see if you can come up with something. You can try searching for something called "LV toolbox", which I believe shows examples of working with windows message queues, Although I'm not sure whether you can intercept messages from other processes.