Create Property or Invoke Nodes from Auto-indexed tunnels

[Darin.K]

This one is really getting to me lately.  I have already admitted to being a Right-Click-ohalic, but I am also a script-ohalic and sometimes XML-ohalic.  I have many situations where I have an array of references which I need to iterate over.  Should be very simple, wire the array to a for loop and add the appropriate property or invoke node.  Creating property or invoke nodes from a right-click menu is very efficient, you get the list for whatever reference type you clicked on.  For some reason, auto-indexed tunnels in for loops do not allow you to Create Property for ... or Create Method for...  If you manually wire a property or invoke node to the tunnel you get the proper class so it shouldn't be too hard to skip that step and create the property/method by right-clicking the tunnel.

[AristosQueue (NI)]

It's a general bug with "shared variable nodes" -- somehow that feature thinks it gets to be top dog on autoindexing tunnels. No idea why, but that's what the CAR is for. LV 2011 since this doesn't meet the "high critical" bar for LV 2010 at this late date.

[Darin.K]

Not even LV2010 SP1? or one of the earlier fixes. ouch.  Perhaps if I were going to NI week I could have greased the skids a little to sneak this one up....

And BTW, I don't use shared variables so my choices to Create are just the usual Control/Constant/Indicator.

[AristosQueue (NI)]

> or one of the earlier fixes.

It's too late for LV 2010 main release, and the only other release planned between LV 2010 and LV 2011 is LV 2010 SP1. Even though we call it SP1, which holds the possibility of SP2, we only intend to have one SP per release (very bad juju if we have multiple!)

>  Not even LV2010 SP1?

I would be surprised if that CAR could pass the test for 2010 SP1. The service packs are generally for bugs that have no workaround or are serious impediments to work. We want the service packs to There's a lot of effort put into making sure that we don't break anything in an SP, and that generally means not fixing smaller CARs since there's a risk that any code change might have unintended side-effects -- a lesson learned from LV 6.1.1 which required LV 6.1.2 just two weeks later. The SPs go through the same quality validation inside NI as a release, but our beta test pool is much smaller and the length of time that the build has to be played with is much much smaller. Sometimes a smaller CAR makes it through if enough customers clamor for it. So if enough of your friends call into the AEs and report that they'd like CAR #XYZ fixed...

[Todd S.]

Moved to CAR Database

[G-Money]

Moved to CAR database. CAR#233635

[G-Money]

I am changing the status from Completed to Declined because Completed should only be ideas that R&D say on Idea Exchange, actively developed on it based on the idea, and it was added to the product

[G-Money]

Moved to CAR database. CAR#233635

[matt.baker]

What is the status of this CAR?

It still doesn't seem to be working in LV2017 (experienced this annoyance since day one, but only just made the effort to ask for it to be changed)

Example shown below. The workaround is to create a broken wire, which is annoying.

[AristosQueue (NI)]

@matt.baker I checked the status. The CAR was closed, rejected, in 2015, as too low priority to fix given the priorities of LabVIEW NXG.

[matt.baker]

That's understandable. Thanks for letting me know.