Flush Event Queue doesn't work with "Key up"

[comrade]

Hi,

probably just a simple thing I am missing here. See the attached VI (including SubVI). In case 1 I fetch the Key Up event for ENTER and issue a Value Change on the Stop Button. This results in a check for the string length and in case it is too short brings up a dialog telling you the ID string is too short and brings you back to the ID entry. Unfortunately - when confirming the dialog with ENTER instead of using the mouse on the button theKey Up event fired again and therefore fetched by the Event Structure.

So I thought I just flush all events in the queue. To be sure, I put a time value on the flush function which proceeds AFTER the dialog is completed, so the ENTER Key Up should be deleted as well. Bummer is - it doesn't work. Anyone know why?

I tried as well with the dynamic event, which I unregistered right after the Stop Event is issued in the Key Up case. I then "re"register for the Key Up event at the same time/position as the flush event queue function is positioned now in the VI below. Still no joy.

What is my mistake? Thanks a lot.

[comrade]

Really no one having an idea about this? Or is it just too abvious what I am doing wrong? Any assistance is appriciated. Thanks, folks.

[Julika]

Hi! Have a look at the following Link: Probably Example 2 can help you. Flush Event Queue Function - LabVIEW 2014 Help - National Instruments http://zone.ni.com/reference/en-XX/help/371361L-01/glang/flush_event_queue/ Best regards, Julika Spitz

[comrade]

Thanks, Julika, for your answer.

Actually I was under the impression that without any connection to the "Event type or Object" connector ALL events would be discarded. In case I got this wrong - is there a way to get a reference to the ENTER button of the Single Button Dialog window? Just assuming the ENTER is associated with that button and the Key Up Event is not fired just by pressing the ENTER, without any bindings to an object...

Could "Key jitter" be a problem?

[Julika]

Hi when you change the property in the event "Key up", case:true from value (signaling) into value, the event isn't fireing again. You can't create a reference to the buttons of the dialog box.

[crossrulz]

My advice is to just get rid of the Key Up event.  Instead set the Key Navigation on your stop button to toggle on "Return".  You should also turn off the Update While Typing on the ID input.

[comrade]

Julika:

1. Changing from "Val(SGL)" to "Val" in the Key up event won't perform what I'm trying to do: The key up on RETURN is supposed to fire the Stop button event, so the check on the length is carried out. If I put "Val" property instead, this won't be performed.

crossrulz:

1. I can't turn off the update while typing because a check is performed on every character entry whether the character is allowed (here: just numbers)

2. I tried using Toggle on RETURN however this leaves me with having to change the focus from the string control to the button. What I try to achieve is to just hit RETURN when I'm finished without first having to "tab" to the button. As a workaround it would be acceptable, however I don't understand 2 things:

a) Why is the Key up event even fired? It doesn't come from the VI where the event structure resides and to which "Instance" the event is bound (VI->Key up), but from the dialog box (which is a different VI). Unless a calling VI inherits all events from its SubVIs or something like that.

b) Why isn't the event fired by the button in the dialog box discarded as the flush event queue function is supposed to perform?

Apart from achieving what I wanted to do I'd like to understand the WHY instead of just realizing and accepting the WHAT.

Thanks for hanging in there, people.

[crossrulz · Accepted solution]

---

@comrade wrote:

I don't understand 2 things:

a) Why is the Key up event even fired? It doesn't come from the VI where the event structure resides and to which "Instance" the event is bound (VI->Key up), but from the dialog box (which is a different VI). Unless a calling VI inherits all events from its SubVIs or something like that.

b) Why isn't the event fired by the button in the dialog box discarded as the flush event queue function is supposed to perform?

---

Because you are slow.  Not you personally.  But compared to the computer, you just don't stand a chance.  So you hit the Enter button on the dialog.  That dialog's OK button activates on the key down.  So the dialog is long gone by the time you manage to get your finger off of the Enter key.  In fact, you loop should be back around to be waiting for an event first.  So it is waiting for an event when you finally get your finger off of the button.  Hey, we have a Key Up event!

Your current checking for the validity of the id is just flat out annoying.  Use the Key Down? event to check for a valid character being entered.  Notice the '?' in my choice of event there?  That means it is a filter event.  This means you can throw away (discard) the character being pressed before the control even sees it.  You could also discard if there are already enough characters (Greater Or Equal, not Equal).

[comrade]

Well, I feel sheepish...

That really clears matters up. So the blamed Return on the dialog box is not the culprit after all.

Also thanks for the hint on the Key Down filter event.

Solution marked and Kudo given.

[billko]

---

@comrade wrote:

Well, I feel sheepish...

That really clears matters up. So the blamed Return on the dialog box is not the culprit after all.

Also thanks for the hint on the Key Down filter event.

Solution marked and Kudo given.

---

Don't feel bad.  As you found out, it's not obvious the first time you deal with keystrokes.  😄