Break bad wire branches, not the entire wire!

[altenbach]

Currently, having one misconnected wire breaks the entire wire tree and pressing ctrl+b wipes out everything. Poof!

In the vast majority of (my) scenarios, a broken wire is due to a small problem isolated to one branch so it does not make sense to drag the entire wire from the source to all valid destinations down with it and break everything in the process.

Here is a simplified example to illustrate the problem (see picture).

In (A) we have mostly good code. If we add a wire as shown, that wire (and VI!) must break of course because such a wire would not make any sense.

However, it does not make sense to also break the good, existing branches of the wire (the cluster in this case), but that is exactly what we get today as shown in (B). If we press ctrl+b at this point, all broken wires will disappear and we would have to start wiring from scratch (or undo, of course :)). Even the context help and tip strip is misleading, because it claims that the "source is a cluster ... the sink is long ...", while that is only true for 25% of the sinks in this case!

What we should get instead is shown in part (C). Only the tiny bad wire branch should break, leaving all the good connection untouched. Pressing ctrl+b at this point should only remove the short bad wire.

The entire wire should only be broken in cases where nothing is OK along its entire length, e.g. if there is no source or if it connects to two different data sources, for example.

Summary: Good parts of a wire should remain intact if only some of the branches are bad. Wires that go to a destination compatible with the wire source should not break.

(Similarly, for dangling wires, the red X should be on the broken branch, not on the good source wire as it is today)

Implementation of this idea would significantly help in isolating the location of the problem. Currently, one small mistake will potentially cover the entire diagram with broken wires going in all directions and finding the actual problem is much more difficult than it should be.

[AristosQueue (NI)]

> The shock value of the entire diagram getting covered with

> broken wires after a small innocent mistake can be very scary!

I'm confused. How is changing the behavior of one wire going to fix something that is breaking wires throughout your diagram? If you have one of those cascade type failures, how is drawing one branch differently going to keep wires from breaking everywhere?

[altenbach]

What I meant: I sometimes have long wires with many branches and a small wiring mistake in a far branch (e.g. due to the slip of a mouse) will currently turn all of it black, all the way back to the source (which might even be off-screen). What just happened!???

> If you have one of those cascade type failures, how is drawing one branch differently going to keep wires from breaking everywhere?

As in the idea image, many wires are still good in principle because the mismatch is isolated to one branch, so they should not break. There should be no failure cascade that breaks everything else all the way upstream to the source and down all other branches. That was the point! 😉

Earlier I mentioned that wires with (e.g.) two source should be broken. Maybe it should be smarter here too and look at the edit history and watch out for unbroken>broken transitions and the last edit operation that caused it. For example if I have two separate unbroken wire trees and accidentally wire them together somewhere in the middle, only the new part should be broken, leaving everything else good. In general, if wires are good and a new connection causes them to break, only the new connection should be broken.

I Admit that I probably would need to spend significantly more time to evaluate all possible scenarios and how it should behave. That's why we are having this discussion and everybody can chime in. :D.

[AristosQueue (NI)]

I'll try to stay aware of this in my work over the next few weeks... as I said, there was a time when I thought I wanted this. Maybe enough has moved around in LV that I'd be ok with this these days. Or maybe I'll remember exactly what made me shy away from it.

[Dan_Lauber]

AristosQueue raises a good issue: case tunnels.  See the example at right (same code, just showing the contents of both cases).  Which code path is the "correct" one?  Right now it seems LabVIEW picks the string type to win as the tunnel source, but for no good reason (I actually wired the Numeric first).  I think edit history is one possible solution, giving precidence to the original type of the tunnel.

I also Kudo the cursor hint that a wire source is incompatable with the terminal you're about to wire to.

My addition to the idea: highlight the good branches in a wire with a broken branch, but only break the broken branch.

[Intaris]

I would say the "Correct" wire is the wire which on its own wouldn't be broken. (Numeric left, String right)

[Dan_Lauber]

Those are two views of the same case statement, so the tunnel has two sources (in different cases), and two sinks - thus two valid code paths depending on what type LabVIEW chooses for the tunnel.  LabVIEW seems to prefer making the tunnel string-typed.

Altenbach's comment of breaking the whole wire if there are multiple sources is another way of solving it.

[Intaris]

I thought you were showing an edit.

In this case the decision needs to be understandable based purely on the current state of the code. I would be against using edit history for this.

[altenbach]

>  the decision needs to be understandable based purely on the current state of the code

Yes, typically wires need to break from first principes.

I can think of one exception as described: If the addition of a new wire fragment currently would break the entire wire, only the just added wire fragment should break at this point. However once we e.g. delete another part of the wire branch it could become valid, of course.

Here's a quick very simple illustration how it should behave when we do the two editing steps marked as (A) and (B).

If the VI is saved after step (1), it should re-open "more" broken, of course, because there is no history. Only the wires up to the first branch should be unbroken.

[AristosQueue (NI)]

> only the just added wire fragment should break at this point.

I definitely do not like that slippery slope. It leads to two identical diagrams being broken in different ways based on order of wire drawing.

[altenbach]

Yes, I understand that this could get very tricky and maybe it is a bad extension of the idea.

I was thinking about it more in terms of a "delayed guesture" similar to what you were talking about here. Basically, instead of a feedback of "you probably should not do that" it would say "you probably should not have done that".

Once we "let them make the gesture and let the IDE explain what broke and why", a small broken segment is a much more precise explanation ("This is the part that just broke things, without it, the rest would be fine! Once you press Ctrl+B everything will be fine again!") compared to just turning everything black ("You just made a mistake somewehere along this huge spiderweb of wires. Go figure out where the problem is! No matter what you do, don't press ctrl+b or everything of it will disappear!").