use default if unwired

[Karl65]

When using case loops and tunnels there will be a lot of wires in some cases just to make the tunnels connected. If you are using "use default if not wired" the default value can't be set by the user. The idea is that the user may specify the output tunnel in the default case and this value is then used as default in following cases where the tunnel is unconnected.

I have made a test vi that shows what I mean.

Karl

[altenbach]

What is a "case loop"? Just because you misunderstood the function of the "default" case of the case structure, does not mean the we can suddenly redefine everything from scratch, breaking all legacy code the relies on the existing behavior. The idea is also way too limiting. What if we want to retain the current behavior for some tunnels?

The default case has no connection to the tunnel behavior. It is the case that gets executed whenever none of the other cases match.

A much better solution to this has been proposed long (5 years!) ago. See here for details.

[Karl65]

Sorry if I opened my mind for a new idea, but you don't have to be impolite if someone is proposing a new idea. Your "better soultion" is not cleaning the diagram, still there will be wires from left to right. I think, if this is a function asked by many, the develper will also find a solution....."brain storming".

If you haven looked in the attached test.vi, where you can find a case in a while loop (case loop), please take a look. I know about minimizing the number of wires with cluster, but using cluster will always result in unbundle vi.

Yes, the default case will be executed when there is no match on the input, that's why I have put the default in case 2, so the user has to connect wires on the output tunnel in this case but not in all other cases. In case 1 is the possibility to initiate refnums, variables and so on.

This new function could be solved by a new selection by right clicking on the tunnel, where you may select "Use Case default value if unwired".

Karl

[crossrulz]

As Christian said, that is not the point of the Default case.  And your idea would break A LOT of my code.  To do this properly, you need a seperate, obviously deciferable place to define the defaults.  The default case is not it.  That's why I gave Kudos to Christian's idea from 5 years ago.

[Karl65]

Actually I don't understand why you are so worried about your old code. If this function would be implemented as new, as my proposal above, this will not make any change to old codes. If you are creating a new diagram or making changes in old, it would be an option where the user may set the default value by him self by selecting this via right click on the output tunnel. Then it's up to the users to decide on how to make the code. In my case I would use it for IMAQ refnums. After an init (create) in the first case, I don't have to transfer the refnum in a wire in every following cases.

Here is an example on how the right click menu on a tunnel may look like

Use default if unwired

Use default Case value if unwired  (new)

Linked Input tunnel >

.

.

.

[crossrulz]

That example makes it even worse.  Now you have to assume that the default case has even ran.  Otherwise you get an invalid reference.  So what you really need here is a shift register or feedback node to hold your reference.

[altenbach]

> Sorry if I opened my mind for a new idea, but you don't have to be impolite if someone is proposing a new idea.

Nobody has to be sorry for anything. All contributions are very welcome. 😄 That also why I was very polite in my answer. Nobody should be impolite and I am not sure why you even brought that up. Seems offtopic for this discussion.

> Your "better soultion" is not cleaning the diagram, still there will be wires from left to right. I think, if this is a function asked by many, the develper will also find a solution....."brain storming".

There will always be wires from left to right, but in my idea they only need to be defined once in one single special case. All outputs with default behavior don't need to be wired in any other cases.

> If you haven looked in the attached test.vi, where you can find a case in a while loop (case loop), please take a look.

There are a couple of things that don't make a lot of sense. For example you have a linked tunnel pair for the cluster, but it is actually not wired across in your default case. However in case "fourth", the cluster is wired across (different behavior than in the default case!), but you complain that the wiring is not nicely drawn. A linked input tunnel will not carry data across in cases where it is not wired across.

> I know about minimizing the number of wires with cluster, but using cluster will always result in unbundle vi.

What's wrong with "unbundle"? Nothing! Even better, if you logically name all your cluster elements, using "unbundle by name" will result in clean and self-documenting code. Highly recommended!

> Yes, the default case will be executed when there is no match on the input, that's why I have put the default in case 2, so the user has to connect wires on the output tunnel in this case but not in all other cases. In case 1 is the possibility to initiate refnums, variables and so on.

As Tim already said, that seems very dangerous because it requires that the cases are called in a defined order.

> This new function could be solved by a new selection by right clicking on the tunnel, where you may select "Use Case default value if unwired".

As I said, you are overloading the default case with new and confusing functionality. This idea won't get my support.

[AristosQueue (NI)]

Karl65: I raise the issue of readability of the block diagram. Suppose you write a diagram using this new feature... what is the experience of someone reading it later?

I opposed the particular implementation of the feature that allowed users to iconify typedefs on the block diagram. I like the general idea for iconification, but when the iconified typedef has a non-default value, I have seen too many times where people are totally confused trying to debug a program until they realize that there's a value inside that constant that isn't the one they expect. In my opinion, we should have put some sort of halo or glyph to inidcate "this iconified typedef has a non-default value". I was overruled, but my experiences since then confirm my concerns.

The same issue would arise with your feature -- you would have terminals on the other frames that draw with the glyph that means "use default if unwired", but they would not be using the default-default. Users would need to know that the hollow tunnel does not mean "default default" value, but instead this other computed value from the other frame. To avoid misleading readers, we would need to draw the tunnels differently...

... and that raises a very big problem, believe it or not. There are many ideas on the Idea Exchange that have hit a wall because tunnels are very small -- and most users tell us that they want tunnels to stay small. That gives us very little room to add decoration to indicate different modes. Color shift is not enough for color blind users, and it creates data type confusion.

With your idea, I also question how execution highlighting would work, ESPECIALLY if your default case allows for any modification of the value as it flows across. The example VI that you posted doesn't modify that default wire, but there's no reason that someone couldn't put an Increment node or somesuch on that wire and say "that's what I want for my default value for all these other frames". We either allow that or we add new errors to the diagram if you put any nodes on that wire. And we still have to flip frames to execute both during execution highlighting. I believe that would be awkward at best.

Basically, I see your argument for making writing the diagrams easier, but I think it falls down when I consider reading the diagrams.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.