LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Nested If and else without case structure

Dear PaulG,

 

Its not about confusion to someone.

 

We want to know, In Simulink we are not using switch case but we are making big logics. They same way I'm trying to collect some information about how much possibility is there in LabVIEW to make any logics without switch case.

 

BR,

munna

 

Munna
0 Kudos
Message 41 of 45
(1,279 Views)
The case statement is the equivalent of that multiport selector that you linked to so your statement is silly.
0 Kudos
Message 42 of 45
(1,266 Views)

A few things occurred to me when reading through this thread:

 

-The "Don't use this type of XXX" is pretty arbitrary, no matter the language you're talking about. It's like saying "build this house but don't use a hammer".  You're still going to end up using a hammer-equivalent or misappropriating another tool at some point.  Either the requirement is poorly stated or poorly justified.

 

-What is the real issue?  Code readibility?  Bad experiences in the past?  If at one point the customer was handed a single-VI state machine with an arbitrarily large number of cases in one structure, then yeah, they might come up with a stipulation like "no case structures".  Handing them new code that does elaborate inscrutable things to avoid using case structures is just going to make them stipulate "No Selectors" next time. Take a step back and ask them why this is a requirement, as I'm sure there are better approaches that would benefit both parties. You can probably even improve their understanding of LabVIEW as well as this hypothetical "bad old case structure code" that they are unhappy with. Going back to the hammer analogy- someone probably complained that hammering was too loud the last time someone built a house in the area.  It doesn't mean that banning hammers is a good way to solve the problem.  Better in-code documentation (flow charts, project tags, etc.) would probably be more useful than instantly-accessible block diagrams. 

 

-There was mention of a Switch and Multiport Switch in another tool, and "switch" wasn't allowed.  I'd argue that a selector in LabVIEW is closer to a "switch" whereas a case structure is a Multiport switch. This is really a semantics issue, and different languages are going to have different semantics and tools available.  Using a different flavor of nearly-identical tool is just a way to work around the reason for these requirements and leads to situations where the customer points at something and says "I thought we said not to use that", and you reply with "No, you said not to use this very similar thing, which we didn't do".  The customer won't be happy.

 

-If this was purely a theoretical exercise, then I'd offer the following as a possible solution to your logic puzzle:

 

Untitled.png

At the very least it'll allow you to specify a single code path to execute.

 

Don't do this in any real application.  It won't make you happy, it won't make the customer happy unless they really don't understand the environment, everyone loses.  It would be a nightmare to scale or maintain with any sort of complexity.

 

Best Regards,

 

Tom L.
Message 43 of 45
(1,255 Views)

Dear Tom L,

 

Thank you so much for your valueble information and other intrested idea.

 

 

BR,

Munna

Munna
0 Kudos
Message 44 of 45
(1,246 Views)

Back on the ignorance of accepting a requirement of not using a case structure.  Because all cases should be visible?  On any remotely complicated program, that is information overload.  Even most text language IDEs allow you to collapse code.  Why?  Because of information overload.  The developers don't want to see everything because it just becomes confusing way too easily.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 45 of 45
(1,222 Views)