Diagram Disable Structure without output tunnels should not break the VI when all its subdiagrams are disabled.

[Ironman99]

The behavior of the Diagram Disable Structure is puzzling me a bit, and it seems somewhat inconsistent.

It seems primarily designed for testing alternative parts of code. At least one subdiagram must be enabled or the VI will be broken.
For this type of use DDS is easy to use: just go to the frame you want to enable, invoke the context menu and click "Enable this subdiagram." Simple and straightforward.

However, I wonder what the "Disable this subdiagram" menu item, that appears for all the already enabled subdiagrams, can be used for. Using it the VI becomes automatically broken.
This behavior is correct if there is at least one output tunnel. DDS cannot forecast which subdiagram I intend to enable, and since one have to be enabled to provide value(s) to its output tunnel(s), the VI cannot be executed. IMHO in this cases the "Disable this subdiagram" menu item, should be greyed out.

However, IMHO, another common use of the DDS is disabling part of a diagram momentarily useless, for testing purposes. For example the code for writing a big log file already tested, while debugging other parts of the VI. In this case, and in all cases where no wires at the DDS output are present, the VI can be safely executed even if all its subdiagrams are disabled. It would be great to have the possibility of directly enabling and disabling the front subdiagram. In this cases the DDS could even have just this subdiagram.



However, currently, to disable the (momentarily) useless code you must go to a blank frame and enable it. Why this convoluted path?

My proposal is:

when no output tunnels are present, the DDS could have all its subdiagram disabled, and the VI should stay runnable. To make clear this possibility, in this case only the "Disable This Subdiagram" context-menu item should be enabled.

Cheers.

Marco.

[Mads]

One thing that I find a bit non-intuitive with the disable structure is that if I only have two subdiagrams in it and I disable the currently enabled one - it does not automatically enable the other.

As you point out automating such a behaviour would not necessarily produce a wanted result (and it would not work if there are multiple subdiagrams anyway) but with the current behaviour (where the VI is broken because all cases are disabled), it would make more sense.

So - if the current behaviour is kept (or in any case; if there are outputs from the structure), I would request that in cases where there are only two subdiagrams, the second diagram should be enabled automatically when the other is disabled.

[johnsold]

If there is some reason due to the way this works internally that disabling all subdiagrams is not feasible, automatically create an empty subdiagram whenever the last empty diagram has something placed in it.

A also agree with Mads that for two subdiagram systems toggling should be easy.

Lynn

[vt92]

I like this idea.  I find the current behavior very annoying. 

[altenbach]

This should have nothing to do with the presence of output tunnels. Having all cases disabled should not break the VI, but simply output defaults for all output tunnels.

In fact, placing a diagram disable structure on the block diagram, should only result in a single disabled case. Having an additional enabled empty case does not really add any useful functionality. If we need more cases, we can always add some.