List of clone in memory

[DanyAllard]

Hi there is a cool addition to LabVIEW 2013, it's now possible to open a VI Clone of a reentrant VI with this menu:

But it's not possible to get this list by VI server.

In the past Version of LabVIEW the Clone number start with :1 so that way it was possible to guess the Clone name and get reference on it. As you can see the number is now very big so there is no more way to guess the clone name  and get reference on it.

I have a tool that depend on this capability of retrieving the list of cone in memory but since the old way don't work anymore, I have to find an other way.  

So I propose to add a Property in the VI Class that return the List of Clone In Memory of the specified VI.

[X.]

That is insane! Why have changed the clone numbering scheme? This will break legacy code. 

[drjdpowell]

See here for a subVI that generates the clone names in 2013.  I'm not using 2013 yet, but I intend to use this to fix my tools that require this functionality.

[X.]

Thanks. Still. What the h@#$k does AQ mean by undocumented? Since when is the name of a VI an undocumented feature? It reminds me of the executable are zip file .. not anymore catastrophe.

[DanyAllard]

Thank you for the link drjdpowell, it will be usefull as a workaround... we still need this property to be added to get ride of this workaround

[SteenSchmidt]

Duplicates of this and this.

Cheers,

Steen

[AristosQueue (NI)]

X. : The clone numbers that you got were always unstable, they just had a very high percent chance of starting at 1, but it wasn't reliable. This just increased the probability to near certainty that they weren't near one. It provides a MASSIVE performance boost for code working with clones. After a lot of discussion on the team, we compared this to someone writing code that depended upon two parallel nodes executing in a particular order and us changing the compiler to put them in a different order. And given that this was a change to functionality that should never have worked in the first place, this wasn't seen as a bad change.

Undocumented refers to the ability to open clone VIs using Open VI Reference. The documentation says you're supposed to be able to open a ref to a VI using the name of the VI. If you test the VI Name property for a clone VI, you get the same name as the real VI. The idea that someone would pass in something that wasn't the VI Name and thus get access to the clones was never considered by the dev team. And the clones are explicitly designed to NOT have second references open to them. They become unstable and will crash in various cases. Changing that isn't really an option for various reasons.

[Darren]

Duplicate of http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Have-All-Clones-included-in-AllVIsInMemory-property/id...

[DanyAllard]

Aristos : My tool I have created is only a helper tool that give the possibility to stop VI that run in the background like clone. When I debug my app, that use class, I got some situation that all classes are locked because there is a clone VI that as not terminate correctly. In this case the solution was to close the entire project and restart. With my tool I was able to find quickly the clone that is causing the Lock and stop there execution. Considering that a second reference is BAD, maybe we can consider to add this new property as a scripting property and restrict there usage. 

[AristosQueue (NI)]

Dany: You're in the same situation I and others are stuck in. I've been trying to brainstorm ways to add something to make the debugging easier, but at this point, it's functionality LV just doesn't have and the work to get there is substantial.

[DanyAllard]

Thank you Aristos