Jump to content

Open lib:VI by name?


Recommended Posts

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?

Link to comment

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).

Link to comment

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?

Link to comment

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.

Link to comment

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?

Link to comment

> 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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.