LabVIEW Developers Feature Brainstorming

Showing results for 
Search instead for 
Did you mean: 

Looking for user feedback on an If-Then-Else-If structure

We are looking for user input on providing an If-Then-Else-If structure in LabVIEW.  This structure would allow users to group together code that comprises an "if (x), then (y), else (z)" statement (including multiple "if(), then()" pairs) without using nested case structures.  A design for this feature could look like the attached mock-up.

In the mock-up, the "if" code is on the left of each frame while the "then" code is on the right.  The last stacked frame contains the "else" code.  Users would be able to add comments for each frame on the selector and drop down on the selector to see a description of all the "if,else" pairs.  As soon as an "if" statement is found to be true, the "else" code will execute and the structure will have completed its execution.  If no "if" code is found to be true, the "else" code will execute and the structure will then have completed its execution.

This is a common feature in most procedural programming languages.  However, LabVIEW has done without it for many years.   Would you find adding this feature to LabVIEW to be useful? Right now we are not looking for feedback on the design specifics of the feature, we are more interested in determining how useful it would be.  Are there cases where you think that this structure would come in handy?  Can you describe a general use-case that you have for this structure?  Better yet, can you provide some examples of code where you think that the Else-If structure would simplfy your block diagram? 

Thanks for your feedback!

Message Edited by Support on 07-24-2006 01:19 PM

Message 1 of 14
Screen shot is attached here:

0 Kudos
Message 2 of 14
Hmmm, I dunno.  I agree that the multi-level nested case structures problem is an area where LabVIEW code is MUCH more difficult to figure out than reasonably well-structured & indented text programming.  Personally, I have a tough time with anything beyond about 2 levels of nesting.
However, I'm not sure that a graphical "Else" clause would be the best solution.  I'd have to think on it more, but my first impression is that you'll still be stuck with some significant awkwardness regarding the precedence of the comparisons, i.e., should I first check "abs(val) > threshold" or check "i >= 1000"?  Better scroll through my frames and see if I've got it right...
Personally, I don't find myself nesting case structures to handle precedence situations very much.  I usually get stuck nesting in dependency situations, i.e., when the inner nested case comparison/selection is relevant only within the context of a particular outer case value.  I've got no good ideas how graphical programming can resolve the confusion caused by this kind of nesting.  My tendency is to try to use one of the formula script nodes that lets you use a small subset of c-like syntax.  I can fit more logic in less space more clearly that way.
I'm interested in what others think though. 
- Kevin P.
0 Kudos
Message 3 of 14

Basically I think this could be helpful, sometimes I have nested case structures and for me it would be more comfortable, if I could click through all possible cases on one structure instead of switch the case of the outer structure and then switch the case of the inner structure.

What I would find better than just if...then...else would be a if...else if structure. Ok this could be built like a switch - case using the case structure and build numbers out of boolean conditions, but I'd prefer one combined structure.

Using LV8.0
Don't be afraid to rate a good answer... 😉
0 Kudos
Message 4 of 14

Hi Christi

Apart from the readability of your screenshots, (too small) I feel that nesting is exactly what happens in a case statement inside a case statement.

The default is a perfect else, so the only thing we could wish for is a space saving "nest"


greetings from the Netherlands
Message 5 of 14
I think it would be helpful in many situations. I have another suggestion that relates to this title. It would be nice if all stacked structures could also be viewed as a sequence. So the programmer could toggle between case stack and case sequence. Case sequence would take more space but would be easier and faster to read.

Message Edited by Tomi M on 08-27-2006 04:44 PM

Message Edited by Tomi M on 08-27-2006 04:44 PM

Tomi Maila
Message 6 of 14

YES YES YES!!! PLEASE....    I like my graphical code to be a concise as possible, and the current method of making a simple if, then statement is a clunky real estate hog.  (unless you wanna give us zooming? hahaha... that's another argument tho.)


take for consideration this case:  i have a status display on my front panel,  i have a vi that maintains a refnum to this control in a shift register, so displaying status messages throughout my app to the main FP is a simple vi call with a string.  What i like to do is simulate the "#define _debug" mechanism from C to display debug messages during development.  All i want to do is check the global "_debug" status and if true, call the status display vi...   what i have to do to get there is a huge case statement wrapping a vi call... which takes up precious square inches of BD real estate, for what...  an if, then?


 I don't even think you need to go as far as what you have illustrated in the attached image...  what if you reversed the select statement from the comparison palette?  one boolean input could determine the path of dataflow...   giv the ability to right click and choose the output type for each of the options. 




Message Edited by joshuatree on 08-28-2009 08:32 AM
0 Kudos
Message 7 of 14

Frankly - I'm not sure if this new structure is quite the right way to implement.  I commonly use I T E I.png


now that the conditional terminal is available.  Perhaps the tertiary primitave could be modified with a settable property to accept arrays and either return an array of T/ F elements (indexing enabled) or If then- elseif else (Indexing Disabled as shown).  This would IMVHO take up less BD space and allow the same functionality.  without hiding the executing code in a "new" structure Or did I REALLY miss the point



Way off topic----- why do I need to go back to edit and left justify lines above a snippet?

Message Edited by Jeff Bohrer on 11-10-2009 06:31 PM

"Should be" isn't "Is" -Jay
Message 8 of 14
Editing time expired (left justify)
I T E I.png
More like this (sorry)

"Should be" isn't "Is" -Jay
Message 9 of 14

So any updates on this front?

I have been away for quite some time now, so don't know if something is already done in this regard.


Jeff, the method you have shown (thanks for the corrected version, that "Elses" confused me a bit) is quite intelligent. Kudos for that.


Christy, it would be helpful to have something that you have explained.


For example, I am implementing a code in which the operations are carried out according to incoming "Operation Code," which range from 1 to 300, with several "types" of operations.


Now, in order to simplify the cases, in the beginning I try to redirect the operation codes to several loops (using queues).

In this redirection phase:

IF OpCode = "3"

THEN a special operation,

ELSE IF OpCode = "4"

THEN another special operation,

ELSE IF OpCode = "11","14","15","21","24","25","48","100","105" (and several more just for example)

THEN another operation (common to all the above OpCodes)

ELSE (for the rest of the more than 250 cases, which would be very ugly to specify in the case structure)

a common operation.


Now, this can be done using the nested Case structure but not very nicely, or I could put the multiple cases (in the 3rd case) in an array and use something similar to Jeff's technique. But an "Else" condition would come very handy in the last case.



0 Kudos
Message 10 of 14