Open lib:VI by name?

[jdunham]

The App.AllVIs property gives a list of VIs in memory. I want to open VI references to all of them, but I need their paths. Is there a way to go from lib:vi name to path to its reference?

Actually what I want is to find all Vis executing at top level, including clones. Is there another way to get that?

[ShaunR]

The App.AllVIs property gives a list of VIs in memory. I want to open VI references to all of them, but I need their paths. Is there a way to go from lib:vi name to path to its reference?

Actually what I want is to find all Vis executing at top level, including clones. Is there another way to get that?

Why do you need their paths? The open VI reference accepts the VI name (if it is in memory).

[jdunham]

Why do you need their paths? The open VI reference accepts the VI name (if it is in memory).

Oh yeah, I was converting the name string to a path, since it seemed to want that, but I forgot that it accepts strings Thanks!

So the App.AllVIs property doesn't include clones in the list, so I still haven't solved my actual problem of enumerating all the clones currently running as top-level VIs in my current app instance. Is that doable?

[ShaunR]

So the App.AllVIs property doesn't include clones in the list, so I still haven't solved my actual problem of enumerating all the clones currently running as top-level VIs in my current app instance. Is that doable?

The LabVIEW Task Manager may do what you need

[jdunham]

Thanks for the link! I see in its code that it just attempts to open clones 1 to N where N defaults to 100. That seems like a real hole in the VI Server API, not to have a method to find all active processes.

OK, I just read the whole thread, looks like there is awareness of the issue. Too bad there's no solution yet. Thanks again ShaunR for the pointer.

[ShaunR]

Thanks for the link! I see in its code that it just attempts to open clones 1 to N where N defaults to 100. That seems like a real hole in the VI Server API, not to have a method to find all active processes.

OK, I just read the whole thread, looks like there is awareness of the issue. Too bad there's no solution yet. Thanks again ShaunR for the pointer.

What issue? Getting clones?

[jdunham]

What issue? Getting clones?

That VI doesn't seem to find clones started by the Start Asynchronous Call function.

[Aristos Queue]

> That VI doesn't seem to find clones started by the Start Asynchronous Call function.

Bingo. And that's the problem we've been fighting. Worse than that -- opening a second VI reference to clone VIs is unstable. In fact, it was supposed to be impossible, and the fact that some of us have found ways to do it really disturbs the designers. Since the hack works well enough sometimes, I successfully talked R&D out of "fixing the bug" in LV 2012, but I'm not sure I'll be able to do that for 2013. The secondary clone references really aren't supportable without substantial refactoring of the whole VI Server mechanism. I'm trying to convince The Powers That Be that we need better debug support in the same version that our hack disappears, but that's been a hard argument for me to win. Hope isn't lost, but the windmills are winning at the moment.

[ShaunR]

opening a second VI reference to clone VIs is unstable

Can you elaborate?

Does this mean that saving the name of the clone created (at launch) and then opening a reference to it later is "unstable"?