Freezing Tab Control/State Machine

[Victrick]

Howdy all,

Here's the scenario(I've included a sample VI that reproduces the scenario described, so you can download and read that if you prefer): A tab control is being used to structure the user interface so that the user only addresses the controls that are immediately relevant (like breaking down a complex process into multiple stages, like a wizard). The tab control is transparent and the visible tab is programmatically changed (local variable or property node) after the user is finished with each screen (for example, they might press the "Next" button).

The tab switches are implemented in a state machine of sorts: There is a while loop with a case structure inside. Each case of the case structure handles a different state of the machine (and displays a different tab of the tab control). The main while loop has a shift register that holds an enumerated constant that indicates the current state of the machine, and thus the visible tab. At each iteration of the main loop, this shift register is read, and the tab that corresponds to it's state is loaded(using property node or local variable to set the tab value).

Each state of the machine has it's own event handler inside it's own while loop. When the state change action is detected, it terminates the event handler while loop and passes a new value to the State shift register(in the main while loop) to indicate the next state.

If there is no processing after the state change event has been handled, the states will switch no problem. However, if there is any delay whatsoever (like there would be if there is any type of processing that happens between states), double clicking the state change event button will switch the tab, but then freeze the VI completely and nothing short of aborting the VI will bring it back to life.

The Zip file attached contains two VIs, one that demonstrates the problem, and my current (though not ideal) solution - If the visible tab is changed in the event that handles the state change, rather than the next iteration of the loop, the program won't freeze.

I was hoping someone could give me some input - what is the cause of this bug? Has anyone seen this problem before? It seemed to me like this was a perfectly valid implementation of a state machine... am I doing something that is taboo and everyone knows you shouldn't do? Thoughts, ideas and comments are welcome.

[Dennis_Knutson]

I'm not sure why you need two different loops and each with an event structure. I've attached a modified version that I thinks accomplishes the same thing with a single event structure.

[Victrick]

The event handling is divided amongst multiple loops for the sake of encapsulating the related code - in the actual program, there are lots of controls on each tab and lots of events to handle. Lumping all the events together in a single event structure makes the code less readable then I would like.

The two tabs are supposed to behave like entirely separate dialogs - because in my situation it's not desirable to have to load another VI. (This tabbed dialog resides in the subpanel of a main frame. I don't want to programmatically load a different sub-panel, as these two tabs are enough alike to warrant being grouped together). Plus, each tab has it's own intialization and shut-down sequence - just like a top-level VI might have, which further compl
icates the one event structure approach.

Thanks for trying to help me out, and I appreciate the code snippet, but it wasn't quite the reply I was looking for. Maybe I should have more clearly stated my request.

Any ideas as to the cause of the freezing? To my (perhaps untrained) eyes, there seems to be no logic problems in my original diagram. This is what I see - the inner loop terminates, and the tab control is reset. The front panel is locked until the event completes, and as soon as the panel unlocks, the tabs should be switched so there is no way that the button should register the double-click.

I was wondering if I could get some etails as to the true cause of the freeze. If anyone had some more information about tab controls, etc., it would be appreciated.

[Dennis_Knutson]

I think the cause of the freeze is what's explained in the caveats to using event structures in the on-line help. To quote:

"National Instruments recommends that you place only one Event structure in a loop. When an event occurs in this configuration, the Event structure handles the event, the loop reiterates, and the Event structure waits for the next event to occur. If you place two Event structures in a single loop, the loop cannot reiterate until both Event structures handle an event. If you have enabled front panel locking for the Event structures, the user interface of the VI can become unresponsive depending on how the user interacts with the front panel."

There are other details in the help listing including a deadlock conditi
on caused by a double-click.

[Greg_McKaskle2]

> "National Instruments recommends that you place only one Event
> structure in a loop. When an event occurs in this configuration, the
> Event structure handles the event, the loop reiterates, and the Event
> structure waits for the next event to occur. If you place two Event
> structures in a single loop, the loop cannot reiterate until both
> Event structures handle an event. If you have enabled front panel
> locking for the Event structures, the user interface of the VI can
> become unresponsive depending on how the user interacts with the front
> panel."
>
> There are other details in the help listing including a deadlock
> condition caused by a double-click.

These caveats should be updated to more specifically warn against
this
for statically registered event structures. An event structure working
with dynamically registered events can reside anywhere you want, even
beside another one. You can even place them inside one another, but you
had better know what you are doing there.

The problem with statically registered events is that any and all event
structures on the diagram are always registered, even before they run
the first time and after they run the last time. This feature means
that you don't miss events. The problem is that when the panel locks
waiting for an event to be processed, and your diagram isn't going to
process the event, what happens then. Fortunately, the Abort button
should always work, even on locked panels.

Greg McKaskle