Showing results for 
Search instead for 
Did you mean: 

clear memory of user actions

I am having problems with repeated user actions when labview is in the midst of runnning.  More specifically i have some buttons that say take some processing time when activated and while the computer is processing it if I press on the button again (once or a few times) nothing happens.  However once the processing of the first user action is finished then the second, third and etc... press of the button gets process, even though it had happened a while ago.  I was wondering whether i could prevent this.
I have noticed that this occurance happens under a couple of cases.  The first is what i explained above while the second i have noticed when I have placed an event structure within a case sturcture.  The lock front panel options is off for the event structure but if the user does the event structure while the case sturcture is not satsified nothing happens ....which is good but then if the case stucture becomes true then the process inside the event structure takes place eventhough the user action did not happen again.  To illustrate this example please take a look at the attached vi.  Try pressing "mouse down" in the string 4 times and then turn the case structure true and you will see the numeric indicator increment 4 times. 
It seems the user actions are saved in memory until labview is free to carry them out.  What i was wondering is whether i can prevent this.  The first case (paragraph) is more important than the second to me since i have able to avoid the second so far.
0 Kudos
Message 1 of 5
Your best bet would be to put the case structure inside the events of interest rather than the event structure inside the case structure.  Evaluate whether the case is true or false and only execute the code in the true case.  Some events have the "?" question mark at the end which allow you to discard the event.
Message 2 of 5

i always put event structures in main panel. if you want nobody to fiddle with some UI buttons, then disable the buttons, not the structure. in other words, putting an event structure in a case structure is a design mistake: the event structure still capture the events, even though it will not process them. another option, is the have dynamic event registration for the 'true' case - but i think it would complicate what you try to do.


... And here's where I keep assorted lengths of wires...
0 Kudos
Message 3 of 5

thanks....with your help i have been able to get around the second case so far but it is the first that has me wondering.  When the computer is processing and does not react to user actions right away but instead after it has done its processing it will have stored all the user actions during that time period when it was frozen and then starts applying them afterwards.  To be more specific i have a calculate button that turns into a cancel button when clicked.  If you click on the cancel then it should cancel the calculation, however sometimes it is frozen until the calculation is finished and then it applies all the actions done by the user while it was frozen.  I know I have seen this functionality on other programs so I am not so worried but again if there is anyway to avoid this........not the fact that labview freezes but the fact that it stores user actions and applies them later when i don't want would be great


0 Kudos
Message 4 of 5
I am not completely clear on what you are trying to do but it sounds as though you are performing action inside an event case which takes longer than the time between two events. (My rule of thumb: Do not put anything into an event case which would take longer than tens of milliseconds to execute.) When that occurs I take it as an indication that the action to be performed should be moved to a parallel loop outside the loop containing the event structure.

If you have events for Start some Action, Cancel the Action, and Stop, the event loop would contain only the three cases. Inside each case would be the Enqueue function. Put into a queue the command created by the user action (Start, Cancel, Stop), perhaps as the value of a typedefed enum, and exit the case to wait for the next event.

The parallel loop would implement the Actions. It would probably be a state machine with states: Idle, Perform the Action, and Stop as well as any other states needed. It would sit in the idle state until a Dequeue function received a command from the event loop. The Perform the Action state would need to be designed in such a way that the Cancel command would be received and acted upon promptly.

Look at examples and design patterns for queued state machines and Producer/Consumer pattern.

0 Kudos
Message 5 of 5