Interesting, intermittent problem

[Jordan Kuehn]

Well here's a problem that I'm having trouble with and I was wondering if you guys had any insight. Essentially a front panel event is being triggered twice. Ok, so you say it's probably just queued up a second one. However, there is immediately a primitive 2-button dialog that must be confirmed and a subvi that has a confirm/deny boolean pair that are 'latch when released'. These buttons don't have any key binding that I'm aware of and key focus is elsewhere. Both of these prompts must be confirmed for it to execute and record the action contained in the event as successful. (first one is a confirmation to execute, second one displays data and prompts for confirmation that it occurred.)

Now we've had one of these screens get confirmed before and we though it had been traced down to a MS update. Updated the machines and didn't see the problem. Today, it appears as if it executed a second event and confirmed both screens without the action of the user. Also, cursor is set busy in the event case which should prevent another click. I will point out that this case is not set to lock the front panel. I don't think that should be an issue and cannot imagine how that would trigger both confirm buttons on the dialogs, but there are certainly much smarter people than myself who are hopefully reading this

I'll probably be on the phone with NI first thing Monday morning, but any insight you guys have would be tremendously helpful. I doubt that I can post the actual code due to NDA, but if needed I can mock something up. I tried to describe things fairly thoroughly though.

Darkside crosspost: http://forums.ni.com/t5/LabVIEW/Interesting-intermittent-problem/td-p/1797572

[asbo]

If you're using the Set Cursor VI, that doesn't actually stop the user from clicking - it only changes the glyph. If all of your logic is in this one event case, use the Lock Front Panel option. If not, you can use property nodes to disable the FP while you meander through other logic.

[Jordan Kuehn]

In that case, I can understand a second event getting queued up. What about the two dialogs though?

[MikaelH]

Have you tried to Delete the event case and recreated it?

Maybe even Delete the control and recreate it.

You can also try using the Lock Front panel for the event, and place a SetBusy inside the event, then go to another state in your state machine, do your stuff there with the dialog boxes, and then SetUnbusy, and go back to the Event Structure again.

Cheers,

Mike

[asbo]

A picture's worth a thousand words I'm not visualizing your description very well.

[Jordan Kuehn]

A simplified mock-up. I can add some more functionality if needed. Basically something triggered the event twice and dismissed both prompts with an 'OK' click.

Edit// Sorry, I left out the "Do Something" VI that should be in after the two button dialog and before the display result subvi.

Edit again// There appears to be a bug in the VI snippet thing. It dropped the definition of the event. It's the "Do Action" boolean value change event.

[drjdpowell]

Just a small suggestion, but you could place your code in the TRUE case of case structure connected to the "NewVal" output of the event case. That would drop any double clicks by the user (as the second would be false). Can't help with the dialogs; though the primitive 2-button can be OKed with the Enter key, your second one has no key bindings and thus should require a very deliberate User action to dismiss.

How do you know the event happened, BTW? Are you sure the action contained isn't being triggered by some other method than the event case?

-- James

[Tim_S]

What event are you using? Could it be the event is supposed to fire twice?

[Jordan Kuehn]

Just a small suggestion, but you could place your code in the TRUE case of case structure connected to the "NewVal" output of the event case. That would drop any double clicks by the user (as the second would be false). Can't help with the dialogs; though the primitive 2-button can be OKed with the Enter key, your second one has no key bindings and thus should require a very deliberate User action to dismiss.

How do you know the event happened, BTW? Are you sure the action contained isn't being triggered by some other method than the event case?

-- James

Well, the button is latch when released so there should only be one firing. I know that both dialogs were confirmed because the desired action did occur, and on the confirmation (2nd) dialog the response is logged as either a pass or fail based upon the user's input. It was logged as pass. Also, that action only exists in that specific event.

What event are you using? Could it be the event is supposed to fire twice?

See my second edit. The only event handled by that case is the value change event from that boolean.

[asbo]

What happens if you throw a breakpoint in the case? Are you actually reproducing this issue yourself or are you just getting reports from users?

[Jordan Kuehn]

I cannot reproduce this behavior on my machines and just have logs and the description from the operator to go off of.

[asbo]

You're in a tough position to try and solve this bug - can you go watch an operator repro this bug? There's no obvious flaw in your event structure and to be honest it's probably a human interface issue.

[Jordan Kuehn]

As I mentioned, in the past we have had hints of this behavior when one of the dialogs would get immediately dismissed or the event would fire right away after the completion of the first event. I was able to witness that while remotely logged into the machine. Never did it make it past more than one window, and I don't think it ever skipped the two button dialog, but I could be wrong.

To counter that we updated windows, there was a .net fix, and disabled tap-to-click on the touchpad. Also, while this machine was exhibiting this behavior we plugged in an external mouse and it stopped. Yup, that's a big can of worms and if it's related to the touchpad I'm not overly optimistic about being able to find something on the internet.

As far as this incident goes, it only happened once, but that was nearly catastrophic for us (there's a reason we have two confirmation screens ). We have two people heading to the location of this laptop (Canada) and we can try to reproduce the issue soon.

If by "human interface issue" you mean an operator covering his... then we have considered it and have not ruled it out completely. However, the timestamps between the logged events differ by 25s and the action takes approximately 22s which helps validate the operator's story. It could be possible that we have a combination of the past behavior and an operator reluctant to admit he hit a button twice. Either way the problem still exists. I'll have some more information in a few hours once we get our hands on the machine.

[Jordan Kuehn]

Well, the second dialog (a while loop with simply two boolean controls to stop it) was definitely blown through with no input from the user. I was able to compare time stamps from the end of the action and the confirmation of that dialog, which were nearly identical. Verified that key focus is on neither of the buttons, nor are they bound to any keys. Then moved to an alternate approach that involved using F-keys to trigger an event structure (key up) in the dialog rather than the controls. We were able to queue up multiple events with this approach which led to the screen being dismissed on subsequent sequences. In a last minute solution, I ditched the event structure in the dialog and simply opened a reference to the keyboard and used the keys from that. No time to test much beyond basic functionality. This is all very strange.

[drjdpowell]

Then moved to an alternate approach that involved using F-keys to trigger an event structure (key up) in the dialog rather than the controls. We were able to queue up multiple events with this approach which led to the screen being dismissed on subsequent sequences.

Wait, wait, wait.. I thought the dialog was a simple while loop with two buttons; where'd this event structure come from? If you have an event structure in a dialog you have to be careful to clear any leftover events, otherwise those extra key presses or clicks will be queued up and ready to go the next time the dialog runs. I think the only way to go is to dynamically register for any events you want, and unregister as you exit the dialog. Re-registering on the next call to the dialog will ensure there are no leftover events from last time. Never use statically-registered events in a dialog, as they can't be cleared.

[Jordan Kuehn]

Wait, wait, wait.. I thought the dialog was a simple while loop with two buttons; where'd this event structure come from? If you have an event structure in a dialog you have to be careful to clear any leftover events, otherwise those extra key presses or clicks will be queued up and ready to go the next time the dialog runs. I think the only way to go is to dynamically register for any events you want, and unregister as you exit the dialog. Re-registering on the next call to the dialog will ensure there are no leftover events from last time. Never use statically-registered events in a dialog, as they can't be cleared.

To clarify, that was a quick fix (well not really), and is no longer in the dialog. Yes, prior to this it was stopped by two boolean controls OR'd into the stop condition. Sorry for the confusion.