Disabling 2023 Q3 feature: Double-click to Finish Wire

[BowenM]

I finally got around to installing Q3 update and starting development in it, and I've got to say:  I'm not impressed.

This whole "Double-click to Finish Wire" is driving me batty. It is very common for me to grab a wire coming out of a for loop or other structure, then double click on the outside of that structure to set the wire there to connect to other things. I find myself very frequently creating unwanted indicators all over the place. To take it a step further, I actually can't think of an instance in development that I'd even want this behavior. There are already multiple ways to create indicators; adding an additional superfluous method that overrides previous behavior is just silly.

Anyway, rant aside - has anyone found a way to disable this? 

Second question: Anything up on the Idea Exchange I can go kudo to have this behavior off by default on an install?

[altenbach · Accepted solution]

Try this..

(Yes, I hate that feature!)

[BowenM]

Thanks altenbach. I found the post you linked, but still somehow missed the specific comment you referenced.

Have you made an idea exchange post yet? 🙂

[Darren]

You can Alt-double click to tack down a broken wire, which is equivalent to the double-click behavior in prior releases.

[BowenM]

---

@Darren wrote:

You can Alt-double click to tack down a broken wire, which is equivalent to the double-click behavior in prior releases.

---

Well, that option is better than nothing.

But come on, why wouldn't you make the NEW behavior the alt option instead of override existing behavior with it? That's just silly. And unlike the Ctrl-Scroll to zoom, you can't even point to an industry standard and say "See?  We're standardizing!"

Sure, I could "retrain my muscle memory" and everything would be Skittles and beer... if I was only ever developing on the newest version of LabVIEW. Instead, any given week I am working with 2018, 2020, and 2023 depending on what tester / code base I'm working on. I'm not nearly smart enough to remember "Oh yeah, today I'm working on 2018. Just double click instead of Alt-double click".

Anyway, at this point I'm just complaining. I give it a very low chance that NI will listen to their community and change it back. And in 6 years when all of my testers have finally upgraded to at least 2023 Q3 then maybe it'll stop bothering me. But for the love of god in the future please stop overriding standard editor behavior with nonsense that nobody wants!

[Darren]

---

@BowenM wrote:
 please stop overriding standard editor behavior with nonsense that nobody wants!

---

I'm not in LV R&D, but I do work with them regularly. None of these changes are made in a vacuum. The team assessed that click-based actions to create constants/controls/indicators would make LabVIEW programmers more efficient (in the long run) over the same menu-driven actions. The broken wire creation was assessed to be something that is not performed as often as create constant/control/indicator, and as such, in the long run, would make more sense to be the gesture that required a modifer.

I'm as curmudgeonly as the next middle-aged guy, but my curmudgeonliness (?) takes a back seat to my desire to become a more efficient LabVIEW programmer (in the long run). With the new double-click behavior, I believe there will be short-term annoyance (Auto Tool, anyone?) that will eventually fade. I understand some of y'all may disagree.

[altenbach]

I spend significantly more time deleting unwanted indicators than I could ever save by this "feature". 🙂

! a fan

All my indicators are born on the front panel.

What's next? Auto-assign auto-created indicators to the connector pane? 😮 jk

[BowenM]

Not being part of the team, I'm not sure where your R&D folks came up with the idea that it's more common to create indicators than it is to pull a wire outside of a loop/structure. It isn't even close for me, or for anyone else I've worked with over the years.

Creating indicators in this manner still requires you to open up the front panel and move the indicator where you want it to match the connector pane. I would assert that it is faster, or at minimum equally fast, to just open up the front panel, grab the desired indicator from quickdrop, and place it where you want it. Especially since this method only works for indicators, not controls... it is a half solution. I would still be on the front panel dropping controls, regardless. About the only time I would prefer this method is if I had a cluster that wasn't a typedef (rare for me) that I wanted to create an indicator for. And in those cases, the quickdrop hotkeys are sufficiently easy and fast.

Even if I did buy into the argument that it is better in the long run, what I don't agree with is the choice to override existing editor behavior for it. Even with the Auto Tool, it is trivially easy to return it to old functionality, even to this day. With this change, NI forced a pretty substantial change (i.e. interruption) to the way I program without an officially supported or documented method to disable it.

With other languages, there are dozens of IDEs to choose from, all of them extremely customizable not only with the built-in options, but with plugins and addons. I think this is strong proof that everyone has different desires and ways of programming, and what works well for one person doesn't work well for others. With LabVIEW we're not given that freedom, we are forced to use whatever NI decides is best. While we will never be given the option to choose a different development environment for LabVIEW, I would very much like to choose what features and "improvements" I use. To me it is absolutely unacceptable for NI to interrupt my standard programming flow as much as they did here without being given an (officially supported) method to disable it.

Anyway, that's my last whining on the topic. It is a choice NI has made, and complaining on the forums won't get them to unmake the decision. In the end, I've built a good portion of my career around being a LabVIEW developer. I will accept quite a bit of abuse before I throw in the towel and change my career trajectory. However, the barrier is much, much lower when advising new engineers and shaping the way testers look here...

(in the long run)

[softball]

Commenting BowenM's sensible entry.

The NI R&D team didn't have to consider backwards compatibility.

NI's official new policy is this :

But we’re focused on the future of LabVIEW, not the past.

See this entry ( for some reason published on Linkedin ) :

https://www.linkedin.com/pulse/new-era-labview-nis-commitment-excellence-efficiency-niglobal-7dple/?...

Regards