03-07-2014 11:58 AM
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
03-07-2014 12:14 PM
03-07-2014 12:24 PM
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:
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,
03-07-2014 12:37 PM
Dear Tom L,
Thank you so much for your valueble information and other intrested idea.
BR,
Munna
03-07-2014 02:30 PM
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.