LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Search for VIs with a particular dependency

Solved!
Go to solution

Every once in a while I need to make a change a VI or library that may already be used by code that I have written previously.  The changes that I will make might cause other code that depends on it to break.  I know that this is an undesirable situation and that I could do things like creating a new VI or library rather than changing the old one, or making a copy and changing the copy rather than the original, but there are times when it seems like the best solution is to fix the original VI or library and then mix other code that depends on it as necessary.  Finding all the code with the dependencies of interest can be a challenge.  I would like to be able to search my computer to find all VIs that depend on the VI or library that I will be modifying.  Is there a way to do this?  The best solution would be functionality that is built into the LabVIEW IDE or a VI that someone has written to perform this function.  Alternately, I might be able to write a VI to do the search.  I could search the computer for files with *.vi extensions and then check the VIs to see what their dependencies are.  This could work if there is a way to find the dependencies without loading the VIs into memory (loading many different VIs into memory has issues).  Is there a way to read dependency information from a VI file without actually loading the VI into memory?

To summarize, I have several questions?

1.  Is there a LabVIEW IDE function or other VI that can search specified paths for VIs with specified dependencies?

2.  Is there a way to get dependency information from a VI without loading the VI into memory?

3.  Is there some other way to find all VIs that depend on specified VIs or libraries?

0 Kudos
Message 1 of 12
(2,418 Views)
Solution
Accepted by cbfsystems
  1. Find files that match *.vi*
  2. Search the contents of each file for the string that is the filename of the dependency VI (use only the filename, not the path)
"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 2 of 12
(2,400 Views)

That's awesome!  I'm sure that I have looked at the file contents before, but I didn't realize that the dependencies were there in plain text.  Thank you very much.

0 Kudos
Message 3 of 12
(2,393 Views)

Paths to dependencies in VIs are stored such that each path element is ASCII.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 4 of 12
(2,382 Views)

Follow up question:  Is there any documentation about what information is readable from the VI file.  For instance, is it possible to tell what class or library the VI belongs to?

0 Kudos
Message 5 of 12
(2,340 Views)

In application methods (paul_cardinale_0-1668623078432.png), you can find these:

paul_cardinale_1-1668623111551.png

am.png

 

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 6 of 12
(2,168 Views)

Anc these:

mam.png

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 12
(2,164 Views)

The attached VI is an example of what can be done with those methods.  It edits the VI's icon without opening a reference to the VI.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 8 of 12
(2,143 Views)

Thank you again!  Your last few posts have clued me in to what I think is a better solution than trying to read the dependencies by converting the file to ASCII and searching for the dependency name in the text.  Contrary to what I thought, it appears that I may be able to accomplish what I want by creating a reference to the VI and then using an invoke node to get the VI dependencies.  This will temporarily load the VI and it's dependencies (assuming they are found) into memory, but they appear to leave memory (I didn't think they would) when the reference is closed.  I can deal with each VI that I want to search for dependencies one at a time:  open it, find the dependencies, and close it.  As long as they leave memory when the reference is closed, there shouldn't be any cross linking issues.  It is much easier to get details about the VI this way than trying to decrypt the VI file.  Not only can I get the dependency names, but also their paths, and lots of other information such as shown in your posts.  If the VI belongs to a class, I can also find the parent class.  This is very good.  It's still possible that there may be some problems because of the loading the VI and its dependencies into memory, but I'm hopeful.  

0 Kudos
Message 9 of 12
(2,128 Views)

Maybe this will be useful.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 10 of 12
(2,113 Views)