Retrieve ref to dynamic dispatch VI

[Zyga]

I wonder if someone has found a way to retrieve reference to a vi that is overriding method and has reentrancy set to shared clone. What exactly I am trying to do is to change properties of this VI controls by using externally opened reference. Actually I would like to localize FP at application loadtime (without placing code on "to be localized" VI blockdiagram). When I list all VIs in memory I get stuff like this:

sDataAcquisition.lvclass:editWindow.vi:Instance:6cc60448-8771-4aea-ad60-5635b7cb9c6a.vi
sDataAcquisition.lvclass:editWindow.vi:Instance:b60c6bed-8161-4566-ab34-ae4092625b90.vi
sDataAcquisition.lvclass:editWindow.vi

sDataAcquisition.lvclass:editWindow.vi is a method that overrides one from parental class.
sDataAcquisition.lvclass:editWindow.vi has not yest been called when above list has been populated,  just owning class loaded into memory.
Can someone explain what Instance:xxx-xxx.vi suffix mean? Can I be sure that if I find all of instances there will be no more alocated at app runtime?
I also can find stuff like that, which has longer suffixes tree:

loadDrivers.lvclass:execute.vi:Instance:ed894b20-902d-486d-ae3e-062689901cdc.vi:Instance:c1440502-af17-4937-acbe-a4f891f270d2.vi
loadDrivers.lvclass:execute.vi:Instance:ed894b20-902d-486d-ae3e-062689901cdc.vi
loadDrivers.lvclass:execute.vi
I assume that this is correlated to ancestry hierarchy somehow, but is there any documentation how/when this clones are created?
Getting back to my original goal. I would like to change properties of e.g. sDataAcquisition.lvclass:editWindow.vi and all its clones.

[drjdpowell]

53 minutes ago, Zyga said:

Can someone explain what Instance:xxx-xxx.vi suffix mean?

Those are VIM, VI macros, I think, not your clones. 

To get clones you need to use Open VI ref with the form <VI name>:nn, with nn as a possible clone number.  See the development of the Task Manager.

[Aristos Queue]

On 10/24/2019 at 5:56 AM, drjdpowell said:

Those are VIM, VI macros, I think, not your clones.

Malleable VIs, not VI macros. VI macros is a never-released, LV2016-and-earlier prototype feature.

[Aristos Queue]

On 10/24/2019 at 4:58 AM, Zyga said:

Getting back to my original goal. I would like to change properties of e.g. sDataAcquisition.lvclass:editWindow.vi and all its clones.

The only correct, intended, non-hack ways to get a reference to an existing clone VI is to use the "This VI Reference" node on the clone VI's own block diagram and have the clone send that reference to someone else as part of its own execution.

Any other mechanism was never intended to work and is generally unstable outside of very specific use patterns.

There is one mechanism available, and I requested that R&D leave it working even though it can be unstable, and that is the Open VI Reference node when you pass a string. You can pass the qualified name of the original VI followed by a colon followed by an integer to get a reference to that specific clone. The big big big caveat is that you need to close that reference before the clone is disposed. This technique is used by the LV Task Manager, and that tool is the only reason that this feature remains instead of being fixed as a bug. Unfortunately, it really isn't possible to make this feature stable without a significant performance hit on calls to clone VIs. It wasn't intended to work, which is why there's no official way to do it, just the devs forgot to close Open VI Reference loophole.

Even if you do get a reference to one clone, any properties you set on that clone while running will be set only on that clone. Likewise, anything you set on the original VI ref will only be set on the original VI (with exception of breakpoints). LV has intentionally never created a "me and all my clones" ref (the reasons why are a topic for a different discussion thread).

If you make changes to the original VI BEFORE the clones are replicated, then the clones will have any changes you make. That generally means never calling the original VI as a subVI and instead always calling it through Call By Reference node.

[Zyga]

Thank you for your answers and sorry for not being here for a while.
Based on information from you, I have achived what I needed, but there are still things that are mistery for me.
 

On 10/28/2019 at 7:56 PM, Aristos Queue said:

If you make changes to the original VI BEFORE the clones are replicated,

That was my thinking before I wrote this post. But it somehow did not fit to what was happening in my project. I was loading a class, changing its VI properties and then call this VI using dynamic dispach mechanism. It wasn't modified as I expected. So I suspected that LV preallocate clones for dd VIs while loading class (and I wrongly assumed that those  are VI with "instance" suffix). And this would fit to what was said after:
 

On 10/28/2019 at 7:56 PM, Aristos Queue said:

That generally means never calling the original VI as a subVI and instead always calling it through Call By Reference node.

So I have created this example:

And this is what happens when I call this VI first time I open the project:


What supprised me most is that even though LV has allocated single clone for dd vi right after class loading, changes made on reference to its prototype applies to the clone as well (which, for some reason, is not the case in my project..). And changes applies to clones that are created afterwards which is expected. Exactly the same behaviour can be seen in executable built based on this example.
Second run after project loading, has both clones in the memory from the beginning. Now operating on the reference has no effect on both clones.
 

Edited November 8, 2019 by Zyga