Exit Case Structure Code

[testdesign]

I have a case structure in which one of the cases runs 4 Dialog Box subVIs in order (Dialog Box 1, then Dialog Box 2, then Dialog Box 3, and then Dialog Box 4).  The Dialog Box subVIs are all exactly the same VI call but with different a different dialog message.  The dialog box allows the operator to hit an ABORT button to exit the dialog box.

Basically, if the operator aborts a Dialog Box subVI, I do not want to run any Dialog Box subVI steps that run after it.

For Example:

If Dialog Box 1 is aborted, I do not want to run Dialog Box 2, Dialog Box 3, or Dialog Box 4 subVIs.

If Dialog Box 2 is aborted, Dialog Box 1 subVI would have run, but I do not want to run Dialog Box 3 or Dialog Box 4 subVIs.

If Dialog Box 3 is aborted, Dialog Box 1 and Dialog Box 2 subVIs would have run, but I do not want to run Dialog Box 4 subVI.

What is the most efficient way to do this?

Thanks so much!

[P@Anand]

It depends how you have handled the dialog box implementation. Show us the code so that you would get some suggestion based on your design.

[altenbach]

What dialog are you using? (one button, two button, three button, express, etc.)

Easiest would be to have a 1D array of strings with four entries (i.e. four "dialog messages" as you call it), autoindexing this array on a FOR loop containing a 2 button dialog (for example). Show the conditional terminal and abort the FOR loop if one of the boxes gets cancelled.

Please show us some code.

[GerdW]

Hi testdesign,

Basically, if the operator aborts a Dialog Box subVI, I do not want to run any Dialog Box subVI steps that run after it.

You named it: steps, that run in a certain order!

Whenever you have "steps in a certain order" you should think "STATE MACHINE"…

What is the most efficient way to do this?

Never ask for most efficient without defining parameters/requirements…

[wiebe@CARYA]

Of course, if you call a subVI it could have a "Skip" input, so the case won't be needed in the 'main' anymore.

EDIT: The conditional stop might indeed be even nicer:

Indeed, most efficient for what: Maintainability? Scalability? Readability? CPU? Memory? VI Size? Number of wires? Number of nodes? Etc.

And in general, you don't want the most efficient unless absolutely required. You'd want a solution that is acceptable on all significant criteria. Needing to optimizing for CPU often means losing points on readability.

[paul.r]

Instead of using 4 separate dialog boxes, why not use a custom one that just iterates through four messages? IMO this gives a better user experience than individual popup boxes, and (depending on if it is relevant for the application) its fairly easy to allow the user go back to a prior screen/message.

[altenbach]

---

wiebe@CARYA wrote:

 EDIT: The conditional stop might indeed be even nicer:

That's basically what I had in mind earlier.

Still, I agree with Paul that it is not the greatest user experience to be continually bombarded with dialog boxes. What is the purpose of up to four dialogs? Does their appearance ONLY depend on the answer to the previous dialog or also on some internal state? Why can't it be a single custom dialog with e.g four checkboxes that can be answered in any order. How often does this sequence of up to four dialogs occur (Once at startup? At regular intervals? At shutdown?).

Maybe if you explain in more general term what problem you are trying to solve, we might come up with a much better suggestion.

[wiebe@CARYA]

---

@altenbach wrote:

---

wiebe@CARYA wrote:

 EDIT: The conditional stop might indeed be even nicer:

That's basically what I had in mind earlier. 

---

Yes, didn't read that until I posted... Someday I'll learn not to do that.