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)]

Speaking as R&D: Totally doable. If people really think they'd like it, we can explore it.

For myself: I thought I would like that about a decade ago. I built a prototype of that just for myself once. I didn't like it. Why? Because just as often those "good branches" were the problem, especially inside loops where types feedback on each other. Breaking the whole wire let me see where they wire was routed and fix all the various endpoints.

[Darin.K]

I am not sure how it breaks down for other users, but the number of times I am able to use a broken (but not dangling) wire as a shortcut to wiring a diagram is pretty small.  Far more often I am annoyed when a naughty autowire, or over-/under-caffeination leads to a missed target and (completely) broken wire.  I am starting to think I would prefer that the IDE either not allow or strongly discourage that branch you show to connect.   Perhaps the triple-click you use to stub a wire could also be extended as a barrier to the creation of a broken wire.  While I am at it, it would also be nice if the wire cursor gave some indication what would result at a given time (X=Bad, Dot =Good, but coerced, Smiley = Good).   Maybe not the smiley part, the lack of an indicator could mean it's good.  This depends on the type propagation being able to keep up in real time of course.

[AristosQueue (NI)]

As a generality, when we have a gesture that is sometimes OK and sometimes not (like wiring in this case), every time we have tried to make the IDE prevent the edit, we have ended up with lots of people confused about why they can't do the gesture. As a result, the general policy for my groups has been "let them make the gesture and let the IDE explain what broke and why." The error window and UI on screen does a better job of explaining the problem than a "you just can't do that" ghostbuster's symbol or grayed out menu item. (The mystically grayed out menu items are the worst for generating user feedback "why can't I do this?")

That generality may or may not apply in this case. I mention it only as a guideline.

[Intaris]

Looking at altenbachs picture i notice something. The good branches are thicker than the bad branches.  The difference is small but noticeable. Could we increase the signal to noise ratio of that differentiation?

[altenbach]

I think the thickness depends in some undocumented way on scalar vs. 1D array, 2D array, cluster, etc. of the source or sink. I.e. the thickness of the respective wire. I was never able to use the thickness of the broken wire as a helpful clue for anything. Too unpredictable.

[Intaris]

But it already shows the broken branch differently. The precedent is already there, we just need to fine-tune it.

[PaulG.]

I'm often frustrated when a wire breaks and I don't know exactly where and why. This would help alleviate that. Kudos.

[ouadji]

I agree with altenbach ... it's a very good idea, kudo !

[altenbach]

I think implementation of this idea would dramatically help newcomers. The shock value of the entire diagram getting covered with broken wires after a small innocent mistake can be very scary!  What did I do now to break everything!? This is so hard!

Over the years (no... decades!) of LabVIEW programming, I have learned the art of high-wire programming without safety net. 😄 Sometimes I do dozens of steps where I connect broken wires everywhere and at the end removing a few little connectors causes the entire diagram to magically become unbroken again. All I need to remember is not to ever press ctrl+b during all this, even if there are some wire fragments that are useless and in the way (e.g. not connected to anything). Implementation of this idea would probably keep most of the wires valid at all stages and ctrl+b would become a useful tool again, only removing the really useless wire fragments.

Let's discuss a logical extension to the idea (see if you agree):

• A wire connected to a valid source should never be broken, even if it is not connected to any sink. It should retain its original color (not black!) but be bleached to indicate that it is dead code (... would probably also requre this idea to be implemented ;)). This way we can tack down several wires halfway and are more likely to connect them right after we scroll to see the target connectors (e.g. when temporarily editing on a laptop with limited screen resolution). If everything is black, it is harder to keep things apart.

Broken wires should be limited to wires not having exactly one source (i.e. zero or multiple) and wire branches wired to an incompatible terminal.

[Manzolli]

Like both the original idea & logical extension. Kudos!