GUI locking up, why?

Question

The attached example VI replicates how my VI ended up, I know it needs to be completely redone but I'd like to know whats messing up here.  On running, if the user immediately goes to Page 3 the slider is unresponsive and so are the tabs.  This doesn't seem to be a race condition.  On starting if the user changes the slider, or goes to page 2 before going to Page 3 this doesn't happen.  So what is locking up the GUI.   Note on Page 3 the loop that is poling the slider is still working as the numeric is still being updated.  The GUI gets locked up other ways too.  I have also have noticed that on aborting this VI are restarting the GUI seems to be locked out until one of the event structures runs, at least that is what I think is going on but is not included in this example.
For those wanting the scoop before downloading.  There are three tab pages.  The controls on one are monitored by one event structure, it runs all the time.  Monitoring the controls on the other two pages are turned off and on with a change of the tab control using a case structure.
Attachments:
tab and event structure testing.vi ‏20 KB
just slider.vi ‏7 KB

Answer 1

phillman wrote:
From what my testing seems to show is that if the event structure is within a case structure, and even though the case that includes the event structure is never executed, the event structure is still activated? 
Why the question mark at the end if you tested and verified it yourself?
(The user interaction queues up the event in the event queue and locks the front panel (if so configured) and the event structure will handle the oldest event once it is able to execute.)  
phillman wrote:
It just seems to me that an event structure shouldn't be activated until it is actually executed. 
No, it's the other way around. You need to write your code with the knowledge in mind that events are aways queued up.
Without that feature you would not be able to write a useful program. What if a button is pressed while the previous event has not finished? What if a button is pressed while it is doing an FFT? Should it just ignore the button or should it service it once the event is available to be processed?
For more fancy requirements you can use dynamic event and register/unregister them depending on the program state. It is all possible, but requires significantly more code.
If you really think you have a much better idea how events should behave, please write it up and post it in the ideas exchange. If it is a good idea, it will collect votes.
(More information, for example read rule #1. Once the while loop has completed, the event structure is no longer in a running while loop, violating that rule )
LabVIEW Champion . Do more with less code and in less time .