Nested Event Loop? How else can I do this?

[RJM2]

Hi there,

Just wondering if anyone knows a way around nesting event loops.  I'm having trouble with a loop logically identical to the one posted here.  The "Stop" button (for the inner event loop) is non-functional when I nest the event loop (actually both "Stop" buttons are non-functional).

Can anyone suggest an alternative to this (that will, hopefully work)??

Thanks for any input,

Russ

[RJM2]

Sorry - no nesting event loops.  OK, so I've made an event loop with a while loop inside of it.  In that while loop I'm calling my sub-vi.  However, I'm simply unable to stop that while loop (even though I have a STOP button connected to the while-loop stop).  Any ideas?

Thanks again,

Russ

[CoastalMaineBird]

Pop up on your outer event loop and choose EDIT EVENTS FOR THIS CASE.

Notice the checkbox that says LOCK FRONT PANEL UNTIL THE EVENT COMPLETES.

Uncheck it and your code works.

When you trigger the first event, the panel is locked, and it doesn't respond to clicks because your event isn't finished, but your event cannot finish until you click another button. Also called "deadlock".

Although, in all my programming time, I have never needed such an arrangement. I suggest you re-think your design.

[RJM2]

Uh oh - I've designed much of my program this way.  I have a tab control with a different "function" on each tab.  So the user may want to run a "Manual Titration", so they would click "start" on the Manual Titration tab.  This is checked in the event structure and the code in that event is run.  However, that code often includes more user input.  What would be a better design for a program like this?  Have I missed something obvious?

Thanks much,

Russ

[CoastalMaineBird]

I don't see from your description why you would need a "two-level" event structure. Again, I've been using events since they came into LabVIEW (5+ years) and have NEVER needed a two-level structure. Here's what my programs look like:

1. Define a TYPDEF that's an ENUM. Call it an "Action". It's states are actions you should take: "Open File", "Update Graph" "Enable Buttons", whatever.
2. Your main window code is a sequence. The first few frams are initialization. One of these defines an array of ACTIONS that you should take first. If you only do something once, you don't need to make it an action, but twice or more - make it an action.
3. In one of your frames, have a WHILE loop - this is your main loop, waiting on user input or whatever. The while loop has a shift register, initilized with your initial ACTIONS array.
4. Inside the WHILE loop is a SEQUENCE with TWO frames.
5. In the first frame, you take the ACTIONS array and for each element in the array, you perform the action.
6. In the second frame, you have a single EVENT structure, responding to user clicks. If the Click requires actions, put an array of ACTIONS into the shift register, and repeat.
7. The flow goes back and forth between these two frames until the DONE (Stop, quit,etc) button is clicked.
8. Another frame of the outer sequence does any cleanup necessary.

It sounds complicated to read, but it's really simple: the shift register holds an array of actions to perform, frame 0 performs thos actions, frame 1 translates clicks, value changes, user activity, into actions for the list.

If you need to be in a certain state, then disable buttons, or tab pages, or whatever, until conditions are satisfied.

HTH,

[RJM2]

Thanks very much for your help - that is a much more reasonable way of doing this!

Russ