VI Server: Getting the Reference(s) of the Project(s) that Owns a VI

[Mr._Jim]

OK, here's a question for someone who knows the intricacies of VI server:

Is there a reasonably easy way to get the reference of the project that owns a VI?  (I'm not sure how this would play out if there are multiple instances in various contexts, but maybe I'm overthinking it.)

I see that there's an "Owning App" property for VIs, which means I could probably get open projects from that and traverse those project hierarchies.  That seems like a lot of effort, though.

Thanks,

Jim

[Christian Mergl]

There is no direct way, even when you use the Owning App the projects have to be in memory (open) to get their references.

Why do you want to know the Owning Project of a VI?

Christian

[Mr._Jim]

---

Why do you want to know the Owning Project of a VI?

---

Heh heh...  I'm working on a very large RT application and I'm using a few different conditional disable symbols.  To eliminate human error, I'm also writing a utility that lets you select different "profiles" of conditional disable symbols, depending on how you want to run the RT application.  So far I've successfully automated getting and setting the symbols, but I'm calling the project by its path.  I'm trying to figure out if there's a way to just grab the reference of the owning project.  It's not a vital feature, but it would eliminate one more step.  (And it's interesting)

Thanks a lot for your answer,

Jim

[Ben]

i have not played with that since early LV 8 but I was able to climb up out of the VI into Its calling Library and from there to the project in which it was opened.

As far as my knowlwedge goes a particular VI instance can only be open in one project context although the same VI could be loaded as seperate instances in unique projects.

Even when a VI is not opened from in a porject the is still a generic "project" to handle those.

Early reading of the XControl spoke of the XControl executing in a unique context, but all of my observations have indicated that even the XControls are running in the same context in whcih their own VI was opened.

Well that about summarizes my memory on that topic. I hope there was something in that pile that helps.

Ben

[Mr._Jim]

---

Ben wrote:

i have not played with that since early LV 8 but I was able to climb up out of the VI into Its calling Library and from there to the project in which it was opened.

---

Very interesting...  I did see a "Calling Library" property. (or was it a "Get Calling Library" method?  Naming is approximate)  I never did find the project, but maybe that's because I didn't bother with the calling library thing.

The pile o' information actually had a few other good things to know, too.

Now I know, and "knowing is half the battle."

Thanks a lot, gentlemen.

Jim

[tst]

I don't have LV in front of me, so I can't check, but you should note that it's quite possible that the relevant property is private, in which case you need to do the following to be able to access it:

First, get the LV scripting installer and activate it.

Second, go over to LAVA and find the INI keys which enable the private stuff. After that, even if the project is marked as private, you should be able to access it. If it still doesn't help, do a search on LAVA for "scripting tools" and one of the VIs in the set will probably show you how to get the reference to the project.

[Mr._Jim]

Actually, I do have scripting turned on, which makes the property and method lists nice and long (for better or worse in this case).  The best part now is that you don't have to jump through so many hoops to turn it on, because it's available on the NI Labs page.

[tst]

But if the project property is marked as private (I didn't check, so I don't know) it won't help you if have the scripting license installed - you simply won't see it in the list.

[Mr._Jim]

Hmm...  I already had those keys in labview.ini before I installed the scripting license, so they were probably leftover from before.  I guess I'm probably ignorant on this one, because I thought the scripting license installation turned them on, too.  (apparently it doesn't?)  It looks like I've been taking those private properties and methods for granted.  

This is good to know, and thanks for correcting me on that.

[Christian Mergl · Accepted solution]

@Ben: You are right, from a VI you get the reference of the calling library, from the library you can get the reference of "a project", which is a "Temporary Project X" where X is a increment. But how to get the real owning project?

If the project is in memory you can use the "Owning Application" property from the VI then the "Project.Active Project"which is a private property.

Christian