"Remove and Rewire" feature/bug?

[Darren]

One of my changes in 2014 was to delete constants in the selection list before deleting nodes. In 2013, depending on the order of the selection list, the Equals function was being deleted, along with the constant wired to it, then later we were trying to read properties on the constant that was no longer there. The code errored out, and no further object removals took place. The constants are removed first in 2014, which prevents this scenario from occurring.

Darin, I agree with you that this QD shortcut (and others like it) shouldn't propogate errors between iterations. I'll try to make a pass through the shipping plugins and address this in 2014.

[Darin.K]

When it comes to these things, my motto is "Do or do not.  There is no try"  Either plow through and ignore/handle all errors or completely give up and do nothing.   Stopping in the middle is just weird.

[X.]

I wonder whether this one has been posted before... but here it is.

When cleaning up code, you sometimes end up with a case structure with a pass-through wire in all cases that does absolutely nothing.

This is different from the "wire linked tunnels in all cases", obviously.

The idea is to select both the input and output tunnel, Ctrl-Space Ctrl-R and hope that the wire will be removed from ALL cases and replaced by a straighthrough wire going below (my preference) or zigzag-ing around the diagram (the preference of the facetious NI engineers):

Do this:

followed by Ctrl-Space Ctrl-R and get this:

[X.]

Start from this:

Ctrl-Space Ctrl-R gives:

I would have expected that no reconnection would have been attempted.

[Darren]

If you select only the Equals function, then remove and rewire works as you desire...no connection is attempted.

If constants are included in your selection, remove/rewire will wipe those first, then evaluate what's left. In this case, the constant is wiped, and all that's left is a node with one input/one output. Based on a change made per request upstream in this thread, a connection is always attempted when a node with just a single input wire and a single output wire is selected, no matter what the types of those wires are.

If constants are not included in your selection, then a different codepath is run, which results in the (preferred) behavior.

I'm not necessarily justifying the current behavior, I'm just shedding some light on why it currently works this way.

[X.]

...except that "is equal?" is not a single-input/single output function, but a two-mandatory-input function with a single connection in this case (I mean after removal of the constant).

You are referring to the very beginning of the thread, right?

I can't find a real good reason why I would want a forced connection between two incompatible data types...especially when it ripples down through the code as in the example shown.

[Darren]

---

@X. wrote:

I can't find a real good reason why I would want a forced connection between two incompatible data types...especially when it ripples down through the code as in the example shown.

---

I think the motivation for this change in the first place was that, if you do remove/rewire on something that only has one wire in and one wire out, then you know more than remove/rewire does. Also, the Compound Arithmetic node will accept numerics, so as far as my scripting is concerned, the type of the source and sink are in fact compatible.

At the end of the day, though, I agree with you that this connection shouldn't be attempted. But I hesitate to change the behavior of the shortcut to treat the two scenarios the same (node + constant selected vs. only node selected), since I implemented it that way on purpose, and probably as a result of some other request on this thread. 😉

[X.]

I really don't know what to say. In this particular case, I was lucky that the damage was local, so I could detect it right away.

In more subtle cases, it might not be obvious which step created the broken wires and therefore how far back to undo.

Maybe a warning when the damage is not local? ("This is going to break a lot of code. Do you really want to proceed?").

I know you guys removed my favorite warning when using the Shortcut Menu "Remove Case Structure", but warnings are good, especially when you expect them to protect against yourself.

[X.]

I wonder whether this one is explaining what I have in mind.

Start from this:

The broken wire is not connected to anything, but I have some plans for it.

Notice that it has implicitly a Boolean type.

If I Ctrl-Space Ctrl-R the selection, it wipes out everything:

...while in fact I was hoping to have the Boolean conditional wire reconnected to the broken output.

Edit: BTW, the result is the same when I remove the constant. That is, all wires are cleared. If the output wire is not broken (for instance because it is connected to a structure), then the operation still wipes out everything. I sort of fail to reconcile this with your promise above...

[Jeff-P]

CAR 406215 discussed in this thread was fixed in  LabVIEW 2014.  For a more complete list of bugs fixed in LabVIEW 2014, check the LabVIEW 2014 Bug Fixes. You can download an evaluation copy of LabVIEW 2014 at http://www.ni.com/trylabview/ or if you have an earlier version of LabVIEW installed and an active SSP subscription, you will be able to download the latest version of LabVIEW through NI Update Service.

Regards,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments | Certified LabVIEW Architect