Pulp Posted April 17, 2013 Report Share Posted April 17, 2013 Hello all, I'm trying to create a VI Analyzer test that verifies certain properties of the containing lvproj of a VI reference. For quite some time I thought I was doing well, until I noticed the lvproj I was verifying was already in memory. And when it isn't, OwningApp can't provide its reference. Is there a way to open the lvproj programmatically? Or another way to obtain the lvproj reference? Thanks in advance & greetings, Bart Quote Link to comment
Ton Plomp Posted April 17, 2013 Report Share Posted April 17, 2013 Well a VI does not know if it belongs to a project (it might even belong to several projects, which is bad), so I guess the best you can do is the following: This will look in the folder of the VI for a project file, if one match is found that is returned, otherwise it will look to the folder above the VI project, untill the root of the filesystem is found. If more than one file is found you need an algorithm to find the best match. One option would be the Levenshtein distance Ton Quote Link to comment
Pulp Posted April 17, 2013 Author Report Share Posted April 17, 2013 Thanks Ton, I'll try your approach. So a VI knows which library it is in, but the library (or a VI) does not know which project it is in? Greetings, Bart Quote Link to comment
Ton Plomp Posted April 17, 2013 Report Share Posted April 17, 2013 Yes that's correct a project is a manager of files while a library/class manages code Ton 1 Quote Link to comment
Aristos Queue Posted April 19, 2013 Report Share Posted April 19, 2013 A library *owns* a VI. A VI *is owned* by a library. The two have an indelible link. A VI may be owned by one and only one library. A project merely uses a VI or library. The same VI or library may appear in many projects. A VI is only part of a project when the project is in memory. Any other time, there is no "owning" project. Quote Link to comment
hooovahh Posted April 22, 2013 Report Share Posted April 22, 2013 A library *owns* a VI. A VI *is owned* by a library. The two have an indelible link. A VI may be owned by one and only one library. A project merely uses a VI or library. The same VI or library may appear in many projects. A VI is only part of a project when the project is in memory. Any other time, there is no "owning" project. I noticed today that there is a private method "Owning Project" and it works the way AQ mentioned where it would not work if the project owning it was not open. As an experiment I added this VI to two projects and opened them at the same time. The property worked as expected where the VI running in the context of one project would return a reference to that, and if it was running in the second projects context it would return that reference. This property does differ slightly from the "Active Project" property which is a scripting method but not private. NI does not support private methods and it's functionality may change unexpectedly so use with caution, or don't use it at all. Quote Link to comment
Popular Post Darren Posted April 22, 2013 Popular Post Report Share Posted April 22, 2013 NI does not support private methods and it's functionality may change unexpectedly so use with caution, or don't use it at all. Here's a VI that shows how to do the same thing, but with public properties/methods. Saved in LabVIEW 2012. Get Owning Project Name.vi 4 Quote Link to comment
Aristos Queue Posted April 23, 2013 Report Share Posted April 23, 2013 Hooovahh: Part of why that method is still private is that I objected to calling it "Owning Project" since there isn't an owner relationship. "Loading Project" would be better name. I would rename the VI that Darren just uploaded. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.