LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Remove and Rewire" feature/bug?

Solved!
Go to solution

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.

Message 21 of 120
(1,254 Views)

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...

0 Kudos
Message 22 of 120
(1,243 Views)

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

 

ScreenHunter_001.jpg

 

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:

 

ScreenHunter_002.jpg

 

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?

Message 23 of 120
(1,205 Views)

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?

0 Kudos
Message 24 of 120
(1,196 Views)

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

 

ScreenHunter_001.jpg

 

CSCR yields:

 

ScreenHunter_002.jpg

 

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

 

ScreenHunter_003.jpg

 

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...

0 Kudos
Message 25 of 120
(1,194 Views)

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.

0 Kudos
Message 26 of 120
(1,196 Views)

How did you guess I was sloppy?

0 Kudos
Message 27 of 120
(1,192 Views)

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:

 

remove_items.png

 

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.

 

Message 28 of 120
(1,173 Views)

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

 

ScreenHunter_002.jpg

 

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

 

ScreenHunter_003.jpg

 

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:

 

ScreenHunter_001.jpg

 

and try to CSCR the unit primitive:

 

ScreenHunter_004.jpg

 

This is not very satisfactory either...

0 Kudos
Message 29 of 120
(1,147 Views)

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.

Message 30 of 120
(1,137 Views)