EVENT structure remembers events from previous call?

[CoastalMaineBird]

LV2013, Win7

My customer has complained about this misbehavior, and I made a basic VI to show it.  No one noticed this behavior in LV 7, 8, or 2010.

Given a SubVI with a RETURN button, that is set to SHOW FP WHEN CALLED and CLOSE IF ORIGINALLY CLOSED, then we have what seems to be a misbehavior by LabVIEW.

The SUBVI is normally closed.  If you run the TEST vi and click the DO IT button, the subVI comes up.

If you click the RETURN button TWICE, during that five-sec interval, the button sticks in the DOWN position.  I understand that.

When the timer expires, the window closes.  I understand that.

If you click the DO IT button again, the window comes up again.  I understand that.

But the window will close BY ITSELF, after another 5 seconds !  I DO NOT understand that.

Even if bringing up the window acts to pop out the button, that cannot cause termination, because termination is caused by a VALUE CHANGED event, changing to TRUE!    But it does.

I tried limiting the events in the queue to 1, no change in behavior.

Attached is a test vehicle, try it yourself.

Is this a bug in my thinking, or a bug in LabVIEW?

[crossrulz]

Well, it is still in memory.  So why wouldn't the queue remain?  Remember that the Event Structure is always queueing up events, even if it can't handle them at the time.

And trying to limit to just 1 event won't work since your issue is that 5 second wait.  You click the button and the event will be handled immediately.  So the queue is down to 0 before you even have a chance to click it again (bringing it back up to 1).

If the VI went out of memory, then I would fully expect the queue to be cleared.

[winterishere8]

Good observation. If you run the subVI in highlighted mode, this problem is not reproducable. 

I do agree with you on your previous statement. You select "Return" twice, it executes it the first time and closes the subVI.vi. But the subVI is still queued in memory. So when you make another call, it executed the queued event. 

[pjr1121]

You can probably prevent this behavior by enabling/disabling the "return" button at the proper times.  Enable the button when the subvi first opens to ensure the button is always enabled.  When the Return button is pressed, disable it.  this should prevent a second press from triggering the event structure (only allow 1 user click).

[tst]

To expand on what crossrulz said, with some more technical terms - when you define a static event, the registration for that event (that's the point where it starts queueing up events) happens as soon as the VI that the structure is in enters run mode. That doesn't mean that the VI is actually running, but rather that it is running or reserved for running. The unregistration happens when the VI leaves run mode.

That's why this is not a bug, although it can be classified as suprising behavior if you don't understand the rules of the system (and as a very annoying one if you have users who double click buttons which close dialogs and then complain that they sometimes do something and the window appears and immediately disappears).

If you really want to handle this properly, you should use dynamic registration, but you can also do things like only execute events if the event time is not too close to that of the previous event or I assume in 2013 you can flush the buffer when starting the VI.

[CoastalMaineBird]

when you define a static event, the registration for that event (that's the point where it starts queueing up events) happens as soon as the VI that the structure is in enters run mode. That doesn't mean that the VI is actually running, but rather that it is running or reserved for running. The unregistration happens when the VI leaves run mode.

OK, I understand that.  Although I didn't think about it before, that makes good sense.  The dynamic registration system is the root behavior, the statis stuff just supplies fixed references at RUN MODE time. Fine.

But how is it that the second call, which depends on a VALUE CHANGED event, with a value of TRUE, doesn't just get ignored?

OIC - what is queued is the original event, which IS a transition from false to TRUE.

Funny - I've used LabVIEW for 25 years and never noticed this issue myself.  I guess I thought the event queue was flushed when the window came up.

So, I should use a FLUSH EVENT QUEUE at the start of every such VI, I guess.  I don't want to add a time-check to every single event case.

[CoastalMaineBird]

You can probably prevent this behavior by enabling/disabling the "return" button at the proper times.

Yes, but that adds a lot of code, for what seems like it ought to be innate behavior.

It only comes up when the reaction to the RETURN button is delayed by other factors (computation, etc.).

[CoastalMaineBird]

No, the FLUSH EVENT QUEUE requires a REGISTRATION REFNUM.

[CoastalMaineBird]

Oh good grief.  The REGISTRATION REFNUM is REQUIRED for a FLUSH function UNLESS it is inside an event structure, in which case it is NOT required, but applies to the whole structure, regardless of which event you put it in.

[CoastalMaineBird]

The FLUSH function doesn't seem to do the trick.

It's weird that the INC LUDE STATIC EVENTS input declares a default value of TRUE, but if you create a constant from it, the constant is FALSE.

But anyway, it doesn't change the behavior.  

It certainly LOOKS like it would only happen AFTER the event is called, but the help reads like it applies to the whole structure, regardless of the event case it's in.