Why, O why ?

[Darren]

---

@X. wrote:

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 🙂

---

I have filed CAR 406215 to look into this for LabVIEW 2014.

[Darin.K]

---

@X. wrote:

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 🙂

---

The fix is pretty simple, get the datatype for terminals with broken wires from the wire source, not the sink terminal on the node being removed.   That is how I did it.  It was a long time ago, but I probably chose that route since it is usually not a coincidence that I have a broken wire on the node targeted for removal.

[X.]

Before:

After CSCR:

I understand that some clean up is sometimes necessary, but YOU have to understand that sometimes, clean up is counterproductive... I am not sure how to parametrize this, but in this particular case, it is in fact quicker for me to delete the offending VI and just reconnect the broken wires, rather than CSCR it and then try to realign wires as I see fit.

Did I say that I practically never use the clean-up tool, unless I want to get a good laugh?

[Darren]

---

@X. wrote:

... I am not sure how to parametrize this...

---

Quick Drop's Ctrl-R shortcut calls the Clean Up Wire method programmatically. I was able to reproduce the errant clean-up outside of Ctrl-R with the Clean Up Wire right-click option in a sample VI, so I filed CAR 406456 against Clean Up Wire.

[crossrulz]

---

@Darren wrote:

 I was able to reproduce the errant clean-up outside of Ctrl-R with the Clean Up Wire right-click option in a sample VI, so I filed CAR 406456 against Clean Up Wire.

---

Yeah, I find the Clean Up Wire annoying whenever I have branches in the wire.  I sure hope that CAR gets resolved in 2014 (I know, no promises).

[X.]

Before:

Ctr-Space Ctrl-R results in:

The OR function is still here...

The oddest thing is that in a similar case, I did exactly the same and obtained the expected result:

Before:

After Ctrl-Space Ctrl-R:

[Darren]

---

@X. wrote:

The OR function is still here...

---

I can't reproduce this...are you sure you didn't have a second Or hiding under the first one? 😉

If you can pare down the problem and post it in a VI, I'll have another look.

[X.]

I am attaching a stripped down version of the VI with a short comment.

[Darren]

---

@X. wrote:

I am attaching a stripped down version of the VI with a short comment.

---

Thanks. I was able to reproduce the problem in 2013, but not 2014. Looks like I fixed it with some of my other 2014 tweaks.

[Darin.K]

Darren is a CLA and you do not reach that level unless you adhere to the official mantra of connecting error wires anywhere and everywhere.  What happens next is that the smallest error in the darkest corner of your code blows everything up and the process stops somewhere in the middle.  My guess is that this is what happens here, some probably ignorable error is bringing everything to a halt.  I remember a bug in the icon editor where a simple problem with a single glyph rendered all of them useless.

My guess, no time to check:  Open up the QD shortcut code, I seem to remember wishing I had a larger monitor (or two) last time I tried this.  Somewhere in there you are going to find the classic LV error trap, an unhandled error feeding a shift register in a loop.  First error, and boom no more scripting.  That is precisely why I (and according to AQ only I) whitelist which errors I consider fatal.  No way I let some silly invalid object error grind everything to a halt.  I get scripting errors when I am not even scripting (not really, but they are commonplace).

I wager a virtual beer that unhandled error + shift register = or left behind.

Edit:  I would check that it really is "fixed".  I could get the error in most cases depending on the order of selection.  Some were easier than others, I even managed it in the so-called good case.