New tunnel attribute: "Use Default if Unwired (this case)"

[sbus]

When you use a case statement, the situation arises where in a particular case there is no need to pass an object to an outbound tunnel, while in other cases you do in fact want to pass an object out the tunnel. To keep Labview happy, you must either provide a bogus item to the tunnel, or you can set the tunnel to "Use Default if Unwired".

I *hate* "Use Default if Unwired" because once set, if you simply forget to wire a tunnel, you will not get an error indication telling you that you screwed up.

I do however have a suggestion for how to resolve this:

1. Rename "Use Default if Unwired" attribute to "Use Default if Unwired (all cases)".

2. Add a new tunnel attribute "Use Default if Unwired (this case)". This will cause the tunnel to pass the default value if a tunnnel is unwired,  but only for the case you set it in. In that way you suppress Labview complaints for cases where you explicitly don't CARE what is passed on, and will still get complaints if you forget to wire to the tunnel in one of the other cases.

3. Add a new tunnel graphic for the new "Use Default if Unwired (this case)"  attribute to differentiate it on the block diagram. Use the existing graphic for the "Use Default if Unwired (all cases)" option.  

4. When you set "Use Default if Unwired (this case)"  on a tunnel, Labview should check to see if  "Use Default if Unwired (this case)"  is set in all  other cases for the same tunnel. If so, have a dialog pop up to ask if you want to convert to "Use Default if Unwired (all cases)". But don't set  "Use Default if Unwired (all cases)"  by default; ask.  You might be adding more cases later...

5. The "Use Default if Unwired (all cases)" and  "Use Default if Unwired (this case)"  attributes are mutually exclusive. If you select one, the following behavior occurs and the other is de-selected:

• If you set "Use Default if Unwired (all cases)" at any time (including in the dialog box above) , then "Use Default if Unwired (this case)"  should be cleared for the tunnel for ALL cases in which it was set, keeping things consistent.

• If you set "Use Default if Unwired (this case)" at any time on a tunnel in a specific case, and  "Use Default if Unwired (all cases)" was previously set for that tunnel, ALL cases must be changed to "Use Default if unwired (this case)". The behavior of your code then remains unchanged, except that you can now selectively clear "Use Default if Unwired (this case)" for any case in which you don't want it set for that tunnel.

See the attached picture to see how the current and proposed behavior differs, and to get a look at what the implementation might be.

[SimonH]

sbus,

I'm interested as to why this would be better than not using "Use Default if Unwired" and just wiring a constant in the cases where you don't care about the output.  Right clicking on the terminal and creating a constant will give you a default for just that case without cluttering up the right click menu with another option.

[altenbach]

I agree. If you hate "use default if unwired", simply don't use it. 😄 There is nothing "bogus" about any output. If a wire exits a case structure, "something" needs to be on the wire, no matter what case has just executed.

Your suggestion just adds more degrees of freedom to the handling, thus it makes it even more complicated and increases the chances of coding errors. I also don't like to get interrupted by dialogs when wiring something up. It breaks all natural workflow.

[AristosQueue (NI)]

If I have to do something special for one frame of a case structure, why wouldn't I just create a constant? It seems to me that tunnels have little enough space as it is to display their configuration without creating another special case that someone reading a block diagram would have to understand and recognize.

[johnsold]

I am with the "use a constant" group.

Lynn

[X.]

Sometimes the constant can be a megoclaustosorus which will need to be converted back into an icon (assuming it has not created havoc because the "Auto Grow" was on). And sometimes you want to do that twice out of 37 cases...

Bottomline, *I* can see the use of this option. But to the OP: when Knights uses emoticons in their response, you are fighting an uphill battle. But I have sympathy for Don Quixote's...

You've got my kudo.

[sbus]

I guess then that I'd prefer to completely eliminate "use default if unwired".I hate defaults; I love explicitness. In love *and* programming. I'd rather wire constants all the time then trip over a "use default if unwired". Plus, this supports my contention that the compiler should HELP me fix my software; if there WAS no "use default if unwired" then I'd always get an error if I forget to wire something. As it is now, I don't get an error (if 'use default... is set') instead I get (the incorrect) default, whatever that is...!

[X.]

I guess it is fair to say that most of the use cases for "use default if unwired" are/should be for Booleans (there is one case I expect a True answer from, all other will give me the default False). For other types of variables, the "Linked input tunnel" is/should probably used instead. But I may be wrong.

Edit: now that I think of it, I sometimes use the "use default if unwired" for enums in state machines. But I'd admit with sbus that this is potentially dangerous (create a new case, forget to check the passed enum and you are in serious trouble).

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.