03-25-2009 11:53 AM
Hi Folks,
Nothing too fancy here.
I'm using an EVENT structure to capture keyboard or mouse events for custom operator popups.
The trouble is that about 1 in 10 times, if I program for several popups in a row, sometimes they will trigger with random ghost inputs and never appear to the user.
I tried the trick of looking for keyboard up and "mouse up" instead of "mouse down". But it didn't stop it fully. It seemed to improve it.
I like to either,
A. Fix the problem
B. Clear the keyboard / mouse buffer before we start.
Thanks in advance.
ps. NI is retarded for not creating more and better operator popups. Just had to get that off my chest.
Solved! Go to Solution.
03-25-2009 12:04 PM - edited 03-25-2009 12:07 PM
First question.
How are you running this? You don't have any while loops in the program so your code will only run once. Please don't say you are using the Run Continuously button.
It is also normal practice to put the boolean buttons in their respective event structures, especially for latching action. That way when the event fires, the button gets read and the latching action allows the button to pop back up.
03-25-2009 12:07 PM
03-25-2009 12:12 PM
Okay, that's good.
Perhaps you could post the higher level VI.
I think what is happening is that since you have an event in this VI for Key Up, you are getting the key up events that were actually generated in the main VI, and they are just in the queue when this VI gets called.
03-25-2009 12:33 PM
The most common false fire, is when I have two or more in a row. The first popups up properly. The operator clicks a button. Then the next two popups fly by with false triggers.
is there a way to clear the buffer before I start?
It's true that I don't know if it's the keyboard or mouse ghost triggers?
03-25-2009 04:54 PM
The button event should be changed to "value changed" and the terminal placed inside their respective event cases (this ensured they revert to false once the event fires).
Your VI is broken (at least one wire is missing). Please attach a runnable VI and a simplified caller VI that demonstrates the problem.
05-20-2009 11:12 AM
The answer was:
The firing was coming from me hitting Ctrl-R to run the VI. When I released the letter "R", the first VI saw that as a keystroke and fired.
doh!