Delete and Rewire Improvement Suggestion

[X.]

The Ctrl-Space Ctrl-R is pretty powerful. Witness this showcase of wizardry from LV:

Ctrl-Space Ctrl-R results in this:

No broken wires, even though there is still some useless stuff to remove.

Now, why can't I select the subVI I just removed and the two DVR functions and Ctrl-Space Ctrl-R them (obviously, that was the effect I was trying to get to eventually)?

As a matter of fact, I'd be happy if I could select the two remaining DVR functions (and their connecting wire) and Ctrl-Space Ctrl-R them as in:

But as of today, that's what we get:

All gone!

Suggestion: When a set of selected objects has an unambiguous set of source wires and an unambiguously corresponding set of sink wires, Ctrl-Space Ctrl-R should be able to zap everything and reconnect the unambiguously corresponding wires.

As a corrolary, when there is ambiguity, do not do anything with the wires that cannot be reconnected. Leave them broken. Do not do extra cleaning!

For instance, in the following case:

If I Ctrl-Space Ctrl-R the selection, here is the result:

Note that the DVR wire is connected properly, but the enum constant is gone, even though I did not select it!

[X.]

Case in point for the corrolary: check this other example.

If I wanted to do that, I could just as well do Ctrl-X Ctrl-B (after having selected the constant...)

[Darren]

A few comments:

1.  In the first screenshot, the Control References are not removed.  I think they should be.  The only reason they're not (I think) is because my code is just looking at constants for removal, and Control References are a different class in scripting, so I'm not trying to remove them.  Let me know if you agree.

2.  When multiple objects are removed with Ctrl-R, the operation happens on each object one at a time.  That's why your data wire isn't being preserved...I remove the first DVR node, the pass through type doesn't match (input is data, output is a data reference), so nothing is passed through.  Then the second object is removed.  I agree that this would be useful, but my initial thought is that supporting the removal of multiple objects as a group via Ctrl-R would require some significant rework, and thus, some significant kudos to this idea.  🙂

3.  The removal of the constant is expected behavior for Ctrl-R.  I discuss this in a bit more detail in the NI Forums post you linked above.

[X.]

@Darren

1. Well, to me the QD is called "Remove and Rewire" so, it would make some sense to remove WHAT IS SELECTED, but I am not sure I would be too happy with objects disappearing because they are not connected anymore to the selection I just removed. That could result in some inefficiency. For instance, I may want to REMOVE an object to REPLACE it by a different one (where a "replace" action would create utter mess for instance), so removing the accessory objects wouldn't do me any good.

2. You've got a kudo right there. I understand that it is more work, but you would earn a seat in the LabVIEW Hall of Fame...

3. There is a semantic use of the word "expected" at NI, which we need to clarify. It is expected in the sense that this is what it has been programmed to do. It is not expected by the user (except by the old timers whom you have cast a spell on) who expect the object to be "removed" and the wires to be "rewired". As I argued above, if I just wanted to remove everything, I could select and delete.

[AristosQueue (NI)]

Heh. Darren, I believe the term you want is "intended", not "expected." 🙂

As for the multiple select behavior... I think that could be easily done by calling "Enclose With Structure" method on the selected objects and then doing a regular Ctrl+Space,R on the structure node. Would that work?

[Darren]

AQ: Sadly, I've encountered enough erratic behavior with 'Enclose With Structure' in the past that I'm not yet comfortable using it in production code.  I'll take another look some time to see if some of my concerns have been allayed in a more recent LabVIEW release.

As for the constant removal, I've had several Quick Drop users indicate to me that this is their preferred, or should I say "expected", behavior. 🙂  It's easy enough to add some override behavior to the shortcut...perhaps have you type 'C' or something before Ctrl-R if you want it to preserve constants.  Let's see how many kudos this idea gets before we start talking too much about changing the behavior of what is, by my assessment, the most popular of all the shipping Quick Drop Keyboard Shortcuts.

[X.]

If these "several Quick Drop users" could please step forward and build a case for deleting constants...

[Darren]

---

@X. wrote:

If these "several Quick Drop users" could please step forward and build a case for deleting constants...

---

Ok, I'll start.  🙂  I use Ctrl-R multiple times a day.  I honestly can't recall a time I *didn't* want it to remove any non-pass through wired constants along with the removed object.  If there are constants wired to the object that I still want, odds are I used Ctrl-P to replace the object instead of removing it.

[X.]

But then you are just "removing"... Where is the rewiring?

[Darren]

Ctrl-R the invoke node...refnum/error wires are passed through, boolean and enum constants are removed.

[X.]

Ah OK. We agree that it is the intended behavior. However, I understand that we agreed that in the case I presented in the other thread, it would not.

Although I understand that this is just an example, let me comment that I don't quite see where you are going with this... Are you planning to insert something in between the two propery nodes? Wouldn't you want to combine "Replace" with "Remove broken wire and unused objects" then?