LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how to make vi always active or by pressing a key?

On my system the example I pointed you to tracks the keyboard presses regardless of whether the window is active or not. Even if another Windows application is active.
0 Kudos
Message 11 of 18
(1,097 Views)
Hi smercurio, You're correct about that, on my computer to! But unfortunatly that doens't work well for the programmable button on my tablet PC. I have to press the button several times before this action is "seen" by de labview program. The event structure "listens" much better to a press on the button. 
0 Kudos
Message 12 of 18
(1,088 Views)
Hi khs,
you can also use the win API to activate your window. Maybe the "ShowWindow" function from the user32.dll helps.

Mike
0 Kudos
Message 13 of 18
(1,080 Views)
I doubt that will help since the user is trying to get this to work while the window is not active, and forcing it to become active defeats the purpose. Fundamentally this comes down to what kind of event is being generated by the Tablet PC when you press that "button". Is it a keyboard event, or a mouse down event? Or, is it a mouse down event that's somehow being converted to a keyboard event? I'm not familiar with Tablet PCs, but I think you would need to find out the answer to this question first.
Message 14 of 18
(1,044 Views)

Hi smercurio,

It is definitely a keyboard event!
When I open the keyboard properties (control panel) I see the effect of a press on the button (for example when I program the button to the function "q"  I see a "q" when pressing the button).
But there are some differences with this button and a normal keyboard (both on the tablet PC, when using an external keyboard).
Pressing and holding down a key on a normal keyboard results in continuously generating "q" (I'm still in the keyboard properties field). Pressing and holding down the button results in only one "q". I first have to release the button and pressing it again to get a second "q".

I don't know if this has anything to do with the problem I'm dealing with, but it might be so...

This may also explain why the event structure works fine (only when the VI is active of course) and the Input Device Control you mentioned before doesn’t (however this works great with a normal keyboard, whether the VI is active or not..)...
The event structure waits for the event and the Input Device Control is placed in a normal while loop (with a high looprate of 1ms). The Input Device Control will probably miss most of the button actions because pressing the butting will result in only one character.

This is the tablet PC: http://www.fieldworks.nl/xploretech/XploreiX104DFullRuggedTablet/Afbeelding3.html

0 Kudos
Message 15 of 18
(1,032 Views)
Well, you can always try the Windows API if it's a Windows OS. Instead of using a hook you can poll the key state. An example VI is shown here. The virtual keycode for F2 is 0x71 (hex 71).
Message 16 of 18
(1,028 Views)

Hi smercurio,

I tried the example user32.dll, but this give the same result as the Input Device Control VI’s (with a normal keyboard it works fine, but on my tablet PC it works poor.)

This doesn’t surprise me too much, because these VI’s use the same dll’s.
I placed the user32.dll in the same VI in a separate while loop with runs at a looprate of 1 ms.
I think it is still the same problem as I described above….

0 Kudos
Message 17 of 18
(1,013 Views)

I finally solved the problem using the user32.dll.

When pressing a key on a normal key-board I read this data:

no key is pressed => 0

pressing and holding down the key => 127

releasing the key => 1

pressing and holding down the key again => 128

On my tablet PC the 127 and 128 don’t show up every time a press the button (this explains why it only worked after pressing the key for many times). I changed the way the key is triggerd by only watching the 0 en 1. Now it works great!

Everybody thanks for al the support! Smiley Wink

Khs

0 Kudos
Message 18 of 18
(995 Views)