determining whether a key has been pressed

[kaufman]

I'm using the "initialize keyboard" and "Acquire Input Data" Vis to monitor keyboard input. I'm capturing which characters are pressed and then displaying these into a picture control (all in a while loop). Since the default state of the "keys pressed" output from these Vis is '0' I can't tell when the user has pressed the zero key or if nothing is pressed. Is there a way to distinguish between the two scenarios, where no keys are being pressed and the user is pressing '0'?

basically what I'm doing is in the attached picture

[Will.D]

If you're using LV after V6, you can use an event structure with "this vi" as the event, and "key pressed" as the trigger.  Inside the structure there's the event data node which can give you the ascii value of the key pressed.

I apologize if you've already thought of this/are using 6.x

[jasonhill]

The nice thing about the event structure is it only fires when a key is pressed, so you never have to worry about getting extrainious 0's.  Also, since the structure outputs the ASCII code, you don't have to monitor the keyboard separately.  

Message Edited by jasonhill on 07-18-2006 03:24 PM

[Dennis_Knutson]

I think the event structure is the best but if you want to fix your existing program, it's pretty simple. The default output of the acquire input data is not 0, it is an empty array. However, the default value of index array when the input array is empty is 0. So, you can add an array size function and only if it's greater than 0, do the index array and format into string. The false case would output an empty string.

Message Edited by Dennis Knutson on 07-18-2006 02:26 PM

[kaufman]

Thanks for your replies,
your suggestions have already helped me get it up and running.

-Danny

[kaufman]

I've got another question now. I decided to use the event structure you described jason. I'm also using queues to connect the loop that reads key presses and the loop that draws them to the picture control. It's exhibiting strange behavior though, and I can't figure out why. I'll try to describe what it is doing:

The first time I press a key it draws it correctly (the mouse position is sent into my draw vi and then the letter is drawn at the mouse location). If I then move the mouse to another spot in the picture and press a key, this letter is drawn where the mouse was during the first letter's draw. If I move the mouse again and press a key, it draws this where the mouse was during the second letter's draw. Basically the drawing is always one step behind the mouse moves. It draws the letter where the mouse was when it drew the last letter. I think it has something to do with the queue, but I'm not sure and I'm stumped. Any help is greatly appreciated.

The key read and letter drawing portion of the code is in the picture attached.

[TCPlomp]

Hello kaufman,

what you've got is a race condition. Because there is no data dependency between the read mouse position and the queue read. So what happens, after a letter is drawn the position of the mouse is read and fed into the draw letter routine. This routine is executed when the queue is fed.

To solve this you should wait with reading the mouse position until the queue element is added. This can be done be feeding the error out of the dequeue element into the error in of the read mous position node.

Ton

[jasonhill]

I am pretty sure that you need to capture the mouse position when you capture the key event.  I.e. the property node needs to be in the event structure or at least in the same loop.  With two independent loops, I am not sure when the mouse position is captured....  I would expand the queue to a cluster containing the key string and mouse position cluster.

[kaufman]

Thanks again for your replies.

Ok, so I have one more question. My vi is doing something really wierd. It's returning different mouse positions even when the mouse hasn't moved. In the "key down?" case of the event structure, if you highlight execution you will see that if you press a couple of keys and watch the values, they change even when the mouse hasn't. Is this a bug? Or am I missing something? I've attached the version 7.1 VI below

[TCPlomp]

Hello Kaufmann,

I don't see the same, but in understanding your code I mistakenly removed your scancode function... So a shift release was never detected. If I understand it correct the position of the letters stays the same if the shift key is down?
I also edited your key down event into this (see attachement)

And you could get the scancode of the last <shift-keydown> for the key-up event.
And even better you could read the <PlatMODS-SHIFT> property of the key-down event,

sorry attachments didn't make it. But I used a lot of the settings from the key down-event