"Remove and Rewire" feature/bug?

[X.]

I am a bit surprised by the following result of the "Remove & Rewire" shortcut (Ctrl-Space Ctrl-R).

Start from this:

Now select either one of the "to I32" functions and try the "Ctrl-Space Ctrl-R" trick. Here is what I get for the top one:

and for the bottom one:

Interestingly, if I use a "to DBL", or an "Increment" or pretty much any single-wired numeric function, things work as expected...

[X.]

It seems that it is the "To Integer" primitive.

Check this out:

Ctrl-Space Ctrl-R:

The wire is gone...

[Darin.K]

I have never looked at the QD code, but it seems likely that in the absence of matching data types between input and output wires, the wires are deleted. I am actually ok with this behavior, but it should be easy to add a special case for single input/output wires.

[X.]

That seems to be the correct analysis, as indeed "To Word Integer" etc behave similarly as "To Integer".

Kind of unintuitive at first though...

[Darren · Accepted solution]

The behavior with constants is expected...if Ctrl-R is used, it will remove constants wired to the removed object if they are not wired to anything else. I haven't yet received any complaints about that feature...people seem to want constants to go away along with the selected object when using the Ctrl-R shortcut.

The bullet removal doesn't pass through the wire because, as the code is currently written, the inputs/outputs must match *exactly* in type in order for the pass through to be wired.  Would y'all like me to make an exception for a unary numeric function, and wire the pass-through even though the types may not exactly match?  I can see this being useful...if you're using Ctrl-R in that specific case, it's because you expect the pass-through wire to be preserved, right?

[Darin.K]

The special case I was envisioning is more general than the unary functions, namely any time a node with one input and one output wired is removed, the wires should be connected. Otherwise, why aren't you just hitting delete?

[X.]

---

@Darren wrote:

The behavior with constants is expected...if Ctrl-R is used, it will remove constants wired to the removed object if they are not wired to anything else. I haven't yet received any complaints about that feature...people seem to want constants to go away along with the selected object when using the Ctrl-R shortcut.

The bullet removal doesn't pass through the wire because, as the code is currently written, the inputs/outputs must match *exactly* in type in order for the pass through to be wired.  Would y'all like me to make an exception for a unary numeric function, and wire the pass-through even though the types may not exactly match?  I can see this being useful...if you're using Ctrl-R in that specific case, it's because you expect the pass-through wire to be preserved, right?

---

Where can I file an official complaint? 🙂

Your analysis of this user's state of mind is correct. Darin. K said it better.

[Darren]

The problem you're having is specific to the numeric type mismatch.  In a normal situation (try it with a Match Pattern with constants wired to all the inputs), the constants will be preserved if they are determined to be part of the pass-through data.  In the case of the Index Array and the To I32 function in the original post, the numeric mismatch is the reason the source constant is removed.  If I were to relax the data type matching logic and allow any numeric type to match any other numeric type for the purposes of pass through data, then the wire would be preserved upon removal of the To I32 function.  Does that sound reasonable to you? This is most likely a low-risk fix that I could potentially get into LabVIEW 2012 (no promises).

[X.]

That would be a more "expected" behavior to me. I won't hold my breath.

[Darren]

Ok, I filed myself CAR 342911 and referenced this thread in the CAR.  I will try to get the 'numeric relaxation' fix in for 2012.  If I can't, I shouldn't have a problem getting it in for 2013.