"Remove and Rewire" feature/bug?

[Darren]

Yeah, this has bothered me for a while, too. I guess it took somebody else noticing to get me to look into it. 😛 The way the code currently works, I inspect the data types of the removed object to figure out pass-through wires. And in this case, the removed object's types don't match, so the wire isn't created.

To solve this, I added some code that checks to see if the removed object has only one input and one output. If so, it just tries to make the connection regardless of the types on the removed object. This seems to solve the problem.

I should be able to get this change into LabVIEW 2013.

[X.]

From a metawiring point of view, the "type" of a broken wire is difficult to agree upon... But in that case, since you want to delete the object from which the broken wire is coming from, you should look for matching types before the object and after it (final sink)... and reciprocally in the opposite case. If that makes sense...

[X.]

In my series about Ctrl-Space Ctrl-R (CSCR) unwanted features, here is another one:

In the snapshot above, I use the OpenG Filter Array.vi as an example but I suppose it could work with other VIs (it does not work with all though!).

I wanted to remove the VI and of course I first tried selecting it alone (not shown above) and CSCR-ed it. I got the following result:

Wrong! Of course I wanted to keep the input array (the original VI made more sense that this dummy one).

So I tried to select the VI AND the Filter array and CSCR-ed them.

Bummer! The result is the same as that shown above...

Why?

[Darren]

Remove and Rewire will try to remove any constants wired to the removed item (that aren't wired to anything else). This is intended behavior, and I argue that most of the time, it's desired behavior. 

At the same time, Remove and Rewire will try to preserve any pass-through wires (that's the whole point of the feature in the first place). So in your illustration above, these two features sorta compete against one another...one of the constants is kept to preserve pass-through data, but the other is removed. As for which one survives and which one doesn't? The order of terminals on the removed node determines that...the constant wired to the first terminal in the list wins (i.e., doesn't get deleted), and it looks like the OpenG VI's connector pane orders terminals in reverse.

As for how to fix your problem while maintaining current functionality...how about I loop through the constants wired to the soon-to-be-removed node and de-prioritize any of them that are selected? So when you lasso the item you want to remove, also lasso any constants you want removed as well. I'll move the unselected constants to the top of the list in terms of pass-through preference, so that, if something needs to stick around to preserve a pass-through, any constants you selected will be at the bottom of that list. What do you think?

[X.]

OK, I guess I simplified my diagram too much. Try this:

CSCR yields:

If I select the constant and the VI and CSCR (see below), I get the same result...

None of it makes sense and I don't see what conflict there could be for CSCR to get it wrong, but it does nonetheless!

As for cases with only constants, I think your workaround would do the job, but please look into the case above...

[Darin.K]

I have a very simple rule for situations like this:  you should do what the user asked you to do, no more, no less.  When you start guessing what some/most/all users want you are bound to make people unhappy.

In my opinion, if I want that constant gone I'll delete it. 

If I select a VI and a constant I expect them both to be removed.  You may be guessing that most time people are sloppy, and you may even be right.  However, if too much is removed, there is always undo and then try to be slightly more careful with the selection.

The only simple rule I see here is that selected=removed, likewise not selected=not removed.

[X.]

How did you guess I was sloppy?

[Darren]

---

X. wrote:

As for cases with only constants, I think your workaround would do the job, but please look into the case above...

---

I have filed myself CAR 379564 to look into prioritizing non-constants when deciding on the pass-through wire(s), and then prioritizing non-selected constants after that.

---

Darin.K wrote:

I have a very simple rule for situations like this:  you should do what the user asked you to do, no more, no less.

---

As originally designed in LabVIEW 2009, Remove and Rewire is supposed to remove the selected item(s), preserve pass-through wires, and remove any constants wired to the removed item(s). From what I can tell, this shortcut is the most widely used out of the six that are currently part of core LabVIEW, and I am not aware of any place other than this thread where people have disagreed with the constant removal functionality. The reason we remove constants is that, for the standard use case of Remove and Rewire, you're taking one or more items out of a "train track" section of code. And when you do this, most of the time, you no longer need any constants that were wired to the removed items (remember, the shortcut does not remove the constant if it is also wired to something else). So in cases like these below, which I believe are the majority of cases in which this feature is used, it really is a timesaver to just select the item(s) you want to remove and have the constants also removed for you, without having to select them as well:

I'm hoping that if I can implement the suggested changes above (prioritizing non-constants when determining pass-throughs, and deprioritizing selected constants after that), we can make the behavior as good as possible for the non-standard use cases as well.

[X.]

Not sure this one has been discussed yet, but here it is in a few snapshots:

Now I select the unit conversion object and CSCR it. Here is the result:

Sure, the wire would have ended broken if kept connected. But is is ALSO broken when not connected. Maybe I did not notice the Numeric Control and would have cleaned the problem myself later?

This being said, if I disconnedt the indicator:

and try to CSCR the unit primitive:

This is not very satisfactory either...

[RavensFan]

I think in your last example it comes down to the datatypes of the wires.  It only connects wires across the removed node if they are the same datatype.  Think of boolean array to number function, it just deletes the node and doesn't try to connect the boolean array wire to the integer wire because they don't match.

Now you might think in your example that since the wires are both orange going into and out of the conversion node, they match and should be joined.  But they are not the same datatype.  One is a double, the other is a double with the units of seconds attached to it.  If you tried to wire across after the node is removed, you'd see you have a broken wire.