Call Chain - Much nicer if it returns VI References, instead of VI Names!!!

[sbus]

It would be far more useful if, instead of returning the string VI Name of each item on the call chain, it returned a VI Reference to each item on the call chain.

You can obtain the VI Name from the VI Reference; but not the reverse. The VI Reference indicates which instance of the SubVI on the block diagram of it's caller was the one in the call chain.

If a SubVI appears in multiple places on the block diagram, the call chain as currently implemented doesn't give you enough informatiion to figure out which instance actually was the caller...

[sbus]

Not having this feature, can anyone tell me using VI Scripting how to find the VI reference of each item in the call chain?

Is there a way, given a VI reference, to find the VI reference of that VI's caller?

I need to distinguish between instances of multiple calls to the same VI on a block diagram...

[fabric]

I love this idea, but I think I would like it implemented as a stand-alone function (or right-click option on the existing primitive).

Also, just to throw it out there: It would be great if VI references to CLONES were returned if clones were in the call chain.

[JB]

---

fabric a écrit :
I love this idea, but I think I would like it implemented as a stand-alone function (or right-click option on the existing primitive).

---

Me too

[DFGray]

If you query for a call chain, all VIs in the result are in memory at the time the call chain request is made.  You can get their VI references by using Open VI Reference with the name of the VI as the input instead of the path.  Context can cause issues with this at times, but is usually not a problem.

[JÞB]

I like the RCM option to return either names or VI refs.  Great idea!

[DFGray]

I just realized I did not fully answer sbus questions.

You can find the callers of a VI by using the Callers' Names or Callers' Paths properties.  However, this will not distinguish between different instances of a VI in a single caller.  To do that, you will need to use the Traverse for GObjects VI in the scripting palette to search the block diagram of the caller for subVIs.  Then query each subVI to determine what VI it is pointing to.  Be careful if you have reentrant VIs.  You will need to use pattern matching on the indexed names to get all the indices.

[AristosQueue (NI)]

Even Traverse for GObjects is insufficient in the case of reentrant VIs.

Modifying the primitive is a bad idea. Triggering VI Server would make that primitive VERY slow. It is meant to provide debug and error information, and it can do that without touching other threads or particularly impacting performance. Making it return references would render it useless for most of its use cases.

Now a separate primitive that does the necessary VI Server work would be fine, and I'll kudos the idea assuming that amendment.

[AristosQueue (NI)]

sbus: No, there is no way to distinguish between multiple calls to the same subVI on a given block diagram. You will have to add a terminal to the subVI and wire in some distinguishing constant into the various calls. Even if you had this reference version of Call Chain, you still couldn't distinguish between two calls on the same diagram. The call chain for both would be identical.

[GregR]

If the subVI is reentrant, then getting a VI reference would provide a reference to the specific instance. There is no way to map that to the node it came from but you would get the specific reference inside each call.

However, I don't think we should return references. Returning references is almost certain to take more time and now you have to worry about lifetime management on each of those references even if you only wanted one of them. I'd prefer that we give you enough information to be able to open a reference to the specific caller instance but leave it up to you to open the reference. This might mean encoding more in the name string or it might mean changing the return type from string[] to an array of clusters.

[fabric]

Fair point regarding the opening of references...

With that in mind, I would be very much in favour of getting "more information" to be able to open references to reentrant VIs in the call chain. What about a right-click option to simply return Clone Names for any VI that is a clone (e.g. Foo.vi:2), so that the name could be used directly with "Open VI Reference"?

I realise that this has moved a little beyond the original idea... Should it be posted as a new idea?