Can't open a VI from an lvproj file using its project path.

[JonP]

I want to open a VI from a project file. I have the two obvious things I think I should need to do this: the path to the lvproj file and the project-relative path to the VI ("My Computer\blah\Vi2Open.vi"). But the following code (Close Reference omitted for clarity) doesn't work:

The Open Vi Reference returns this error:

Error 1004 occurred at Open VI Reference in OpenVI.vi
Possible reason(s):
LabVIEW: The VI is not in memory.
To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input.
VI Name: My Computer\blah\Vi2Run.vi

I do not have the full path to the VI available and thought that the Project.Open function brings the VI into memory, it certainly looks like it does from all the "loading" messages I get.

The help for Open VI Reference's "vi path" control says:

If you wire a name string, the string must match the full delimited name of a VI in memory on that target.

I can not find any definition of what a "full delimited name" is. Is there any way to construct one that identifies the project file and its internal path? Or have I got to do something horrible like find the VI in the project file (there doesn't seem to be an easy way to do that) and then pull out its Path property?

I am using LabVIEW 2015

[GerdW]

Hi Jon,

loading a project does not load VIs into memory…

(Maybe that's the reason for your error message? Using a static VI reference does load the VI into memory.)

[JonP]

Thanks Gerd, You are probably right but it sees to me that I should be able to open a VI from a project file easily: Open the project using Project.Open and then call Open from the resulting Project reference. Alas, NI don't seem to provide the obvious API to do that!

[billko]

A project file is just an xml file.  It's only purposes (that I can see) are to organize the VIs and keep track of build info.

If you're going to rely on the project file to open the VI, I guess it would be about as robust to simply call the VI directly using the project path (using the appropriate path constant).

[JonP]

Thanks, Bill. But the Project.Open generates tons of "loading" messages and it takes a long time opening a large project, so it must be doing something - one thing I know it does is create a new "application instance" for VI execution.

I can't use the lvproj path because the project files can use virtual folders and can include VIs from nested sub-folders.

When you write a call using an lvproj file in TestStand you specify the lvproj name (including a path if the file is not in TestStand's search path) and the project-relative name so TestStand must somehow be able to call a VI using those two pieces of information, in fact it shows you the resolved path in the IDE:

Maybe I should ask the question in the TestStand forum.

[wiebe@CARYA]

Opening a project does load some VIs. For instance, classes are loaded, and all their VIs.

Open VI Reference accepts a path specifying the location on file, or a string specifying the name of the VI. It doesn't accept the path in the project as a string.

Open the project, find the VI in the project either get it's path and use it to open the VI, or get the VI refence directly from the project:

[paul_cardinale]

---

wiebe@CARYA wrote:

Opening a project does load some VIs. For instance, classes are loaded, and all their VIs.

Open VI Reference accepts a path specifying the location on file, or a string specifying the name of the VI. It doesn't accept the path in the project as a string.

Open the project, find the VI in the project either get it's path and use it to open the VI, or get the VI refence directly from the project:

---

Nice.  Can you tell us what all the bit meanings are for the Flags input?

[wiebe@CARYA · Accepted solution]

Of course if you have the project, you can manually traverse the project:

Close those references though.

[wiebe@CARYA]

---

@paul_cardinale wrote:

---

wiebe@CARYA wrote:

Opening a project does load some VIs. For instance, classes are loaded, and all their VIs.

Open VI Reference accepts a path specifying the location on file, or a string specifying the name of the VI. It doesn't accept the path in the project as a string.

Open the project, find the VI in the project either get it's path and use it to open the VI, or get the VI refence directly from the project:

---

Nice.  Can you tell us what all the bit meanings are for the Flags input?

---

No, because I have no idea.

I experimented (a tiny bit) and found 2 will return exact matches.

I wandered about the flags myself, but unless NI let us know, I don't think there's a (legal) way to find out.

Perhaps just empirically trying out all flags on a DUT project gains some insight, but it will be a lot of work, and no guarantees.

[JonP]

Wiebe, manually traversing the project in the way you have shown is exactly what I implemented a couple of days ago, I was just thinking there ought to be a way to open the VI in a single call, or maybe two, one to locate it and one to open it.

Your earlier solution with the GetFindResults function looks neater but I don't like to use "brown" functions as they are unreleased, right? I don't even remember how to make them show, perhaps you could remind me?