Convert conditional define to case structure

[r_exler]

There should be an option (right click on the structure?) to convert a conditional disable to a case structure.

Why?

a) I often use conditionals to test different algorithms. In several times it finally has been nessecary to implement both (or more) of them into the final application as none of them cover all cases of input data well enough.

b) In other cases It showed that selecting the algorithm should be selectable (e.g. using a INI file or registry entry, a project's global or even from a front panel terminal).

In all cases changing the conditional disable to a case using the values from the conditional cases in use as case values would just leave the work to add the input to the case selector input (whereever it comes from).

[altenbach]

It seems easier to start out with a case structure here, because it is much easier to compare algorithms when you can switch them on the fly while running.

[r_exler]

Yes it might be in some cases. But in other having a case which is never called can add losts of dead code in your application, e.g. if the case not in use accesses libraries as report generation or TDMS streaming which get compiled in the EXE even if never called and causes additional sub-folders to be distributed with the application.

As such I prefer to use conditional defines to switch between versions of a program, e.g. debug (with additional output created) and release. And as mentioned above at the final end I sometimes end up with the need to let the user select between the options.

It should be a simple task to make the option to convert between conditional define and a regular case structure (and even back), while modifying the code by copying into a case structure can be a lot of work depending on the number of wires going in and out as well as a function of block diagram size.

[altenbach]

I am under the impression that if you use a diagram constant as case selector, the code of the other cases is stripped out too, so there is no clear advantage. Still, I agree that your proposed conversion should be implemented. (As well as some others suggested elsewhere, e.g. case <> event).

[r_exler]

If using a constant on the diagram you will be right. But in my projects I typically use one conditional to switch several positions within the VI hierarchy. This raises the need to use a global or similar and then the unused code is definitely not optimized away.

One example happened has been to use different hardware or communication protocols (to be able to reuse the code in different projects). On the end I had the requirement to support both within the same project and had to rewrite all the VI's using the conditional to use a flag from the project's configuration file. Lots of work if you have to convert each occurance of the conditional to a case by hand, each having several options.

[X.]

That's a duplicate of a duplicate (sorta) no less:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Diagram-Disable-Structure-and-Conditional-Disabl...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-the-ability-to-replace-a-disable-structure-with-a-...

but if that helps having this implemented...

I use diagram disable structures sparingly due to this very problem (slightly less complicated than that of the OP). A one of a kind test cannot become a multiple choice test without a painful conversion.

I suppose the "conditional diagram disable" replacement would be more tricky than that of the mere "diagram disable" in the sense that you could very well lose some fancy conditional expressions in the conversion, unless a very non-trivial case naming scheme was used...

[r_exler]

Yes, the conditional diagram disable replacement might be more tricky if you use different selectors in the cases. But this most likely makes no sense as LabView does execute just one of them (the first found) anyway. So checking for OS=windows' in one case and 'simulation=1' in another will lead to unexpected operation: depending on the order of the cases one of them will be exectuted while both conditions might be true.

So limiting the automatic conversion process to replacing the structure with a case and replacing the conditions with a string of the orignal condition it replaces will do most of the work while giving clear instructions to the programmer what to correct to get it working again (doing so, the cases will have "OS=windows", "simulation=1" and "default" as conditions for the dangerous example above). And if the programmer decides to use a numerical as input (e.g. selecting different values for simulation only) it's very easy to rewrite the conditions after applying a proper input value to the selector.

Just a note: I've searched several keywords / combinations before starting this discussion, none of the results pointed me to the threads mentioned above (which in fact address very similar issues).

[X.]

If you had searched for "conditional structure" for instance (54 pages of results!), you would have found the first link on page 3, next to last item (as of today).

When you come up with something very trivial, chances are that somebody has suggested it before, so it is worth browsing a few pages (or add a few more keywords).