GUI locking up, why?

[phillman]

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.

[altenbach]

Your event structure for tab changes is buried deep inside structures and thus is not always in the dataflow. SInce it cannot execute unless it is in the dataflow and is set to lock the front panel until the event completes, you are deadlocked forever. 

[minnellac]

The first clue that there is something bad going on here is where you said, "until one of the event structures...". Please take a look at "Using Event in LabVIEW" in the help. What's happening is that your event structure in the top loop is locking out the front panel because there is an event that is unhandeled. The event can't be handled because you enter a separate while loop that you can't get out without access to the front panel. You can get around this by selecting your Tab Control event in the top event structure and selecting "Edit Events Handled by
this case". Then uncheck the "Lock front panel (defer processing of user actions) until this event case completes.

BUT, this is a really bad architecture. You should handle all the events in a single event structure, and don't enter a while loop from within your main user interface loop. Generally, you want your UI loop to just handle events, and each event should be handled in less than a second (so the UI doesn't seem unresponsive). Anything that needs to happen that takes longer than that (and can't be handled within the main loop), can be taken care of in an independent loop. In this case, the root cause of your problem isn't that you have two event structures, but it's still not a good idea.

Sorry if this isn't clear enough... it's Friday afternoon 🙂

Chris

[altenbach]

You are overthinking this.

A tab control is just a way to logically group and show controls alnd indicators. Many times you don't need any special code on the block diagram. If a control changes, we can assume that it is on the current tab.

There is no need to have extra stop buttons, a "stop...value changed" can be read in multiple event structures.

An event structure belongs on the toplevel diagram of a while loop, it should never be inside cases, inner loops, etc.

Here's a quick draft that shows some ideas.

[phillman]

C. Minnella said:

What's happening is that your event structure in the top loop is locking out the front panel because there is an event that is unhandeled. The event can't be handled because you enter a separate while loop that you can't get out without access to the front panel. You can get around this by selecting your Tab Control event in the top event structure and selecting "Edit Events Handled by this case". Then uncheck the "Lock front panel (defer processing of user actions) until this event case completes.

I kind of see this, and tried the recommendation and it works, but here's what I don't understand.  This top event loop, for Page 2, does not get entered until Page 2 is selected? Then when a new tab is selected, wouldn't this event get triggered, and while loop/event case structure stop because tab control no longer equals page 2?

[Dennis_Knutson]

---

@phillman wrote:

.......

I kind of see this, and tried the recommendation and it works, but here's what I don't understand.  This top event loop, for Page 2, does not get entered until Page 2 is selected? Then when a new tab is selected, wouldn't this event get triggered, and while loop/event case structure stop because tab control no longer equals page 2?

---

Not true at all. An event structure is always active. You've already been told not to place them inside case statements, etc.

[minnellac]

Exactly. when any "handled" event (that is, an event that has a case in any event structure associated with it) occurs, the event structure locks the front panel to prevent other events from occuring until the first one is actually handled by the structure. You have set up your code so that the event can occur, but the case structure is prevented from running to handle it.

Chris

[phillman]

Dennis Knutson said:

       "An event structure is always active"

But once the outer while loop is stopped, is it still active?

Dennis Knutson said:

     "You've already been told not to place them inside case statements, etc."

As the original poster, and asking further questions to understand answers, I find this tone against a user trying to learn the fine points. Telling someone "you've been already told not to do this", when the poster is trying to understand why a particular nested structure is bad, seems to go against the atmosphere of a learning environment.  Not that it bothers me, but I image a more timid person might refrain from asking further questions.

[phillman]

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?   So in my structure, the case tab control=2 contains event structure with an event = tab control value change,   so even if   case tab control=2  is never executed,  the event  tab control value change   triggers it and it locks the  front panel?

It just seems to me that an event structure shouldn't be activated until it is actually executed.

On the other side, if the while loop that contains the event structure is stopped, is the event structure still active?

And thank you Chris for being patient.

[altenbach]

---

@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 ;))