"Remove and Rewire" feature/bug?

[Darren]

---

@X. wrote:

Thanks. Where do I sign up?

---

When it's available, you can sign up at ni.com/beta.

[X.]

Any reason why CSCR doesn't work with control/indicator terminals? Right now, we need to delete said terminal and remove broken wires manually (Ctrl-B being nuclear, this either require deleting one wire at a time or selecting a ROI and Ctrl-Bombing it).

[Darren]

---

@X. wrote:

Any reason why CSCR doesn't work with control/indicator terminals?

---

Currently, Remove and Rewire only recognizes items in the Node class and the FlatSequence class in VI Server as valid objects to remove/rewire. I guess there's no reason it couldn't recognize ControlTerminal as well...when I first wrote the feature, I was only considering objects that could have pass-through wires, i.e. input and output terminal pairs that users would want wired together upon object removal. I guess if you're using Ctrl-Space-Ctrl-R to wipe out objects and their leftover wire ends, it would also be handy to look at ControlTerminals and Constants too. I'll see what I can do.

[X.]

I need to keep focused on something else, so I am just throwing this example at you, just in case that's one we haven't covered yet:

Before:

I select the "OR" function and CSCR it, with the following result:

I was obviously expecting the lower, unbroken Boolean wire to reconnect to the Boolean indicator. Somehow, that's not what your algorithm decided to do and it resulted in something that does not look very sensible to me...

[Darren]

---

@X. wrote:

I was obviously expecting the lower, unbroken Boolean wire to reconnect to the Boolean indicator.

---

I have added another prioritization to Ctrl-Space-Ctrl-R to prioritize unbroken wires over broken wires when deciding on the pass-through wire. This change, along with the change to support removing constants and control terminals, should be in the 2013 beta. Please make sure to go through this thread and try out all of your requests when the beta comes out. 🙂

[X.]

I wish we could have the same level of input on other LabVIEW functionalities...

Thanks.

[X.]

Here is my starting point:

The two string cluster outputs used to be enums, which I converted to strings for added flexibility.

Now I do not need anymore to extract the corresponding enum "string", which I was doing with the little piece of code at the bottom: take the string array from the property node for the cluster element and index it with the value of the enum (code which is now replaced by a string connected to an array index, hence the broken wires).

I was anticipating that a Ctrl-Space Ctrl-R (CSCR) on the Index Array primitive would remove said primitive and figure out that what I wanted was a direct connection of the (broken) string wire with the output string wire. Fat luck!

Instead, I get this:

All wires are removed and no connection is made. Of course the same happens if I do that with the remaining Index Array.

Is there a way for CSCR to do what I was expecting? There is a single ouptput and a single input wire with a compatible type...seems like a no-brainer 🙂

[Yamaeda]

---

@X. wrote:

Here is my starting point:

The two string cluster outputs used to be enums, which I converted to strings for added flexibility.

Now I do not need anymore to extract the corresponding enum "string", which I was doing with the little piece of code at the bottom: take the string array from the property node for the cluster element and index it with the value of the enum (code which is now replaced by a string connected to an array index, hence the broken wires).

 ----------------------------

If you want to get the String of an Enum, i'd recommend Format into String, just wire the Enum as input, no need for property nodes.

/Y

[Yamaeda]

Btw, if Darren is on a QD mission, is the Insert in a split wire issue fixed? If a wire is split and you do quick drop insert it placed the item "first" before any splits regardless of where you inserted.

/Y

[Darren]

---

@Yamaeda wrote:

Btw, if Darren is on a QD mission, is the Insert in a split wire issue fixed? If a wire is split and you do quick drop insert it placed the item "first" before any splits regardless of where you inserted.

/Y

---

This issue is fixed in LabVIEW 2013 for a standard Ctrl-I insert operation with Quick Drop. It is *not* yet fixed for a Ctrl-Shift-I insert of a single object on multiple selected wires.