case structure output tunnel option - take from partner if not wired

[LukeASomers]

So you have a case structure with a bunch of cases where wires proceed straight across unbothered. It could be a state machine with a state queue and error cluster and some persistent state information. It could be a DAQ module action engine. It could be a state case where you pick one of several wires to do something special with and pass all the others through. It could be a bunch of things, hardly matters what.

Wiring these is tedious, a source of error, and distracting in reading.

I think a better way would be to use pairs of tunnels, one in on the left and one out on the right. If the output tunnel of a pair isn't wired for a case, it acts as being wired from its paired input tunnel. These would set up and edit a lot like shift registers - you can link them the same way, and they slide up and down together, and they get a special visual appearance: instead of an up-and-down arrow, both sides would, perhaps, get sharp right-pointing arrows.

[AristosQueue (NI)]

Right click on the output tunnel and choose "Linked Input Tunnel". I believe this is the feature you are requesting.

[LukeASomers]

I began to say 'YAY' but then I tried it and it didn't.

That created an actual visible wire when it did anything at all. I want to avoid having an actual wire going across the case structure. It would act like 'use default value if unwired' with the linked terminal as its default. And that's not what this does.

[RavensFan]

This sounds like a duplicate of A better way to define the output of unwired output tunnel

[altenbach]

Link broken. Here is the correct link: A better way to define the output of unwired output tunnels

[LukeASomers]

That's a lot more complicated than what I proposed - you need to set aside a whole case for it - but that would do the job, yes.

[AristosQueue (NI)]

> I want to avoid having an actual wire going across the case structure.

Ah. I see. That is a request we explicitly rejected when designing the linked tunnel feature. We tried it. Some people objected to the inability to probe the value inside the case. More people found it tricker to read, enough that it seemed like a bad idea. Now, part of that objection was because we did not require the tunnels to be locked across from each other. We force Shift Registers to be locked across from each other, but customers also told us they wanted multiple output tunnels to be linkable to the same input tunnel (try it ... it works). Without that "locked position", we needed the wire to indicate which tunnels were paired.

BUT -- that is not a reason to close this idea. It's an aspect that we certainly could change, and it might be worth reconsidering at some point.

A general comment about ideas proposed for multi-frame structures:  Altenbach linked off to his other idea, which has a high number of kudos. The biggest objection I've heard to that one is that the behavior of any given case is no longer readable looking at just that case. You would need to be able to see two cases simultaneously to understand the case structure. That objection comes up pretty strong when we attempt various other "default diagram" features for any of the multi-frame structures. Now, that objection does NOT apply to your wiring suggestion, but that objection highlights one of the general issues I observe with any suggestions around the multi-frame structures: the writers of the structures want one thing, the readers of the structures want something else. That means that I, personally, tend to support editor features that accelerate filling in the graphical details of the structures but not features that remove the graphical details. It's worth keeping in mind when brainstroming ideas like this one.

[LukeASomers]

I totally agree about prioritizing making the diagram readable. Diagrams are read much more than they are written.

One of the wonderful things about Labview is that you can see cases in context. Labview is better than text languages for this (some IDE features help) - you just pick a case and bam, you are looking at what happens in that case. Having to refer to two panes to understand what's going on in a single pass through a case structure would break that.

One difference, though - sometimes, graphical details are unnecessary and distracting. A bunch of wires going straight across a diagram - or worse, having to follow bendy routes around intervening structures only so they can make it across the diagram unmolested - are distracting. Knowing that they made it across by looking at the right side would be much clearer (once you know what the terminal means, of course, but tooltips).

[tst]

---

@LukeASomers wrote:

A bunch of wires going straight across a diagram - or worse, having to follow bendy routes around intervening structures only so they can make it across the diagram unmolested - are distracting. Knowing that they made it across by looking at the right side would be much clearer (once you know what the terminal means, of course, but tooltips).

---

You might wish to vote for the following idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-breaking-up-long-wires-with-labels-in-each-end/i... . The link is to a comment where I posted a "tunnel entrance" mockup, which I think is something which can help make it clearer that this is what's happening. The diagram I used it on isn't a very good representation of where it would be useful, though.

[LukeASomers]

I think anchoring it at the edge really mitigates the problem that introduces - not knowing just where the other end is. Here, you'd know exactly where it's coming from at a glance.

[LukeASomers]

Addendum: these would also be allowed on event structures.