Expose "Call Chain" as VI Property

[TurboPhil]

The only way I know of getting the call chain of a VI is with the Call Chain primitive, which only works on *this* VI (the VI calling the primitive). It would be nice to expose that as a VI server property, so we could get the call chain of any VI by reference.

[CoastalMaineBird]

It might make sense to have this property that would return a 2D array or array of clusters containing all the different call chains.

MyRef = OpenVIRef('C:\MyFolder\MyLLB.llb\MyVI.vi")

Error = StartAsynchronousCall (MyRef)

What's the call chain for MyVI?

And how do you know it if MyVI isn't running yet, or has quit already?

[igagne]

If it's not running, I think it would have to return an empty array. If it was running it could be like if you ran call chain on it and give you its state right now.

[JimChretz]

There is a Callers property so I think it makes as much sense to have the Call chain for each caller.

If it's an async call there is no caller, just a top level VI. Call chain of a top level contains one element, current VI's name.

[CoastalMaineBird]

What problem would this solve, anyway?

Some sort of debugging monitor?

That's about all I can think of.

[JimChretz]

This would probably be a Property available in developement engine only, not in run-time.

[AristosQueue (NI)]

I strongly doubt that there is any way to implement this request without negatively impacting the execution speed of all VIs. The call chain today is only safe to obtain from within the running VI because only from within the VI can we guarantee that the call chain isn't shifting around. There is today no mechanism to freeze the execution of a VI while some external system crawls up its call chain.  If we were going to try to add a call chain externally, it would have to some way pull all the execution clumps for a given VI off of the execution queues, wait for any that are already executing to finish and then it could climb the call chain and then re-enqueue the remaining clumps. I cannot imagine any intervention in the execution queues that would not somehow negatively impact the running of all VIs just to support this feature.

I'm guessing you're trying to write some sort of debugging feature. There might be some way to achieve this -- I won't rule it out -- but I wouldn't bet on it.

[TurboPhil]

Glad to see this spawned some good discussions. 🙂

At this point, I am convinced it's not practical, and I understand the rationale as to why. I think I can live without it.

The idea actually just came up as I was modifying a "Center Window on Caller" utility, which was initially written with a fixed index in the call chain (e.g. "caller's caller"...since this is a subvi to place inside a VI you want centered, it would get a reference to the caller's caller to find the appropriate window to center on), but then I found myself wanting to wrap that inside *another* subvi, so I realized the fixed index was insufficient.

I modified the "Center on Caller" subvi to use the reference of the VI-to-be-centered, and then find that in the call chain and increment by one to find it's caller. But then it occurred to me that I have a VI that appears to work on an arbitrary reference, but in fact is is limited to VIs within the call chain. I don' t think there will be many use cases where I would *want* to use it outside of the call chain, necessarily, I just don't like having a VI that will only work under certain conditions...I'll have to add run-time checking of the call chain and throw an error if the referenced VI not in the call chain of the subvi performing the centering....and even that might not work if it's a reentrant VI...

But again, probably not a common/realistic use case that might result in the unexpected behavior. (Hopefully)

[Christina_R]

As per the discussion, this would be impractical if not technically impossible to implement.