Interesting, intermittent problem

[jordankuehn]

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.

LAVA crosspost: http://lavag.org/topic/15254-interesting-intermittent-problem/

[tst]

---

@jordankuehn wrote:

Also, cursor is set busy in the event case which should prevent another click.

---

That would be my first guess, because setting the cursor to busy wouldn't help if the user had time to double click the button before the code in the event case started running. Generally, you can filter things like that by checking the event's time terminal and making sure events aren't too close.

My second guess would be a keyboard malfunction, but if the dialogs really have no bindings, that wouldn't explain it.

One thing you can try is adding logging - see when events happen and when dialogs are dismissed (and how, if possible). I don't know if it would help, but it might give you more info you can use.

[jordankuehn]

---

@tst wrote:

That would be my first guess, because setting the cursor to busy wouldn't help if the user had time to double click the button before the code in the event case started running. Generally, you can filter things like that by checking the event's time terminal and making sure events aren't too close.

My second guess would be a keyboard malfunction, but if the dialogs really have no bindings, that wouldn't explain it.

One thing you can try is adding logging - see when events happen and when dialogs are dismissed (and how, if possible). I don't know if it would help, but it might give you more info you can use.

---

I like the time filtering which can probably fix the symptoms, but may not address the root cause. I'll probably implement this right away while continuing to investigate.

As I mentioned a MS update seemed to fix the problem before.  We chalked it off to the Dell touchpad interacting with the .Net framework or something of that nature.  Any thoughts on this?  I hate bringing both Windows and Dell drivers into the equation, but the intermittent nature makes me have to include the possibility.

If it is a problem with the touchpad/buttons, then logging might not help as it would be difficult to distinguish between actual input from the user.

[tst]

---

@jordankuehn wrote:

We chalked it off to the Dell touchpad interacting with the .Net framework or something of that nature.  Any thoughts on this?

---

You could try disabling the touchpad. If memory serves, my Dell laptop has that option and if that's really the source, it might help.

I can say that one thing I didn't like about both my current and my previous laptops (both Dell) is that if you apply pressure to the sides of the touchpad (by placing your palms there, for instance), it sometimes causes the laptop to register that pressure as mouse moves (or possibly clicks as well), even if it's far away from the touchpad. I doubt that's what happening in your case, but since you brought that up, I thought I would mention that as well.

[jordankuehn]

We've disabled tap-to-click and their stupid multi-finger gesture thing.  We have not been able to recreate the problem while using an external mouse, but it's not ideal since these laptops are used in vehicles.  If I can definitively say it's the touchpad then I'm all for encasing that thing in concrete and handing them a mouse.