> Code with all cases of a diagram disable structure
> disabled should be perfectly legal and should not break the VI.
I thought we tried that at one point in beta and had people complain that they forgot to have a case enabled. Maybe we never actually tried it but just talked about the likelihood... my memory is foggy there.
> As long as all outputs have a defined datatype (and they do!),
No, they don't. Different frames can have different data types on the same tunnel. Which frame do you pick for the default type? The first frame? I never keep track of which is first -- to me, they're mostly a ring that I flip through, with no beginning or end, especially the structures with just two frames.
I'm not saying the behavior shouldn't change, just raising a couple issues that feel like the decision you all are coming to aren't considering. Maybe not important enough to derail, but worth noting, I think.
> No, they don't. Different frames can have different data types on the same tunnel. Which frame do you pick for the default type?
Well, the LabVIEW compiler already figured out how to deal with this.
Case in point:
Create a disable structure with three cases.
leave the enabled case empty.
wire a DBL constant to an output tunnel in one disabled case.
wire a I32 constant to the same output tunnel in the other disabled case.
Since the output is not defined in the enabled case, you would argue that the code should be broken, but it isn't! We can actually create an indicator at the tunnel. and there is no broken wire.
I am not saying that I fully understand what's going on, and maybe there is a bug. For example, the tunnel is blue in my case, which does not follow the conventional coercion rules. Even if I change the I32 constant to e.g. CDB, the tunnel remains blue even though there is nothing blue wired anywhere. If I now delete the tunnel and recreate it, it is orange.
Even with incompatible datatypes (e.g. scalar in one and array in the other), the compiler picks a datatype (array in this case), and breaks the code in the other disabled case (which does not break the VI!).
In any case, the output tunnels seems always defined, even with only an empty enabled case. Since an empty case is not interesting, it could be hidden from the UI. That was my idea.
I'm not sure if I get the philosophy under the language properly, but, if you remove the “, Default” case from a Case Structure you break the VI. As I know, there is no way to have a hidden empty default case. Following this principle, I do think that should be always a visible Enabled case with no broken wire.
Stick to the idea of allowing to remove only disabled cases.
Actually, removing the default case does not necessarily break a VI. A case structure that is only True or False does not have a default case. A case structure driven by an enum does not need a default case if there is a case for every item in the enum.
Same for anything. As long as you cover all possible values, no need for a default. For instance: ":..-1" and "0.." will cover all numerics. No default needed.
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
The Disable this diagram menu item has always baffled me. It is a complete waste of time and mouse motion. I mean seriously, why was it ever put there?
Given the current affinity for Use Default If Unwired I see no need for an enabled case. A bit like C++ making me uncomment code.
I am probably alone here, but I would prefer that there always be an explicit enabled case and that the output tunnels default to not using default values. Too many bugs with values not passing through.
tl;dr: either explain why disabling a case is even an option right now or remove it.
@RavensFan: True for Enum, but not true for True/False Case Structure because it never had one “Default”, so you cannot remove it. But the point I want to make, it is still true, in any case: always should be a visible code to be executed. “Default” is necessary when there is a possibility of none of cases be an answer to the data connected to the Selector Terminal, covering any other case not created (coded).
@crossrulz: true and obvious for us, but the compiler is not smart enough to figure out that.
Given the current affinity for Use Default If Unwired I see no need for an enabled case. A bit like C++ making me uncomment code.
I am probably alone here, but I would prefer that there always be an explicit enabled case and that the output tunnels default to not using default values. Too many bugs with values not passing through.
No, not alone. Also, see this. That focuses on event structures, but it also mentions disable structures (and a problem with setting them not to use defaults).
P.S. I did vote for this idea, because I do find myself occasionally wanting to flip a two-frame structure and then being annoyed by the fact that disabling the case didn't enable the other one. I don't do it very often, so I can't say that I really care too much what would actually happen with this.
