How to quickly determine what VI's are not called by another VI in my project?

[flycast]

I am new to NXG and am learning. I appreciate all the help the community has offered.

In the course of developing my first app I created a lot of VI's that were called by other VI's. I would do something with a VI and then later determine that it was no longer needed. Now that my app is mostly finished a lot of these VI's are not needed - orphaned if you will.

Is there a quick way to determine what VI's are needed by my main app -or- more helpful - what VI's are no longer needed by my main app so I can delete the unneeded VI's.

This question also pertains to enums and gtypes.

[GerdW]

Hi flycast,

in classic LabVIEW you can use the VI Hierarchy window.

Or you can right-click items in the project and select "Find callers".

Or you can create a source distribution from your main VI, which includes its hierarchy…

(There might be problems finding VIs called dynamically.)

[flycast]

Hmmm... Hierarchy is nice.

There does not seem to be a "Find callers" in NXG when I RBC which is exactly what I would be looking for.

[altenbach]

---

@GerdW wrote:

in classic LabVIEW you can use the VI Hierarchy window.

Or you can right-click items in the project and select "Find callers".

Or you can create a source distribution from your main VI, which includes its hierarchy…

(There might be problems finding VIs called dynamically.)

---

Don't forget:

• Right-click on project (top item in items view)...find items with no callers. (will also list the toplevel VI and stuff called by reference, so be careful).
• You can also remove everything except the toplevel VI from the project, then copy everything (except vi.lib stuff) back from the (now possibly massive) dependencies branch. None of the orphans will come back.
• Of course removing something from a project is not the same as removing these unneeded files from the disk hierarchy.
• Sorry, not sure about NXG.

[flycast]

Thanks for the responses. Unfortunately, it does seem to matter in that case as none of these LabView answers work or are available in NXG.

[billko]

I have to say, it's a little like saying, "Everyone who isn't here please raise their hands".  😄  Unfortunately, i don't have anything meaningful to contribute.  😞

[flycast]

---

@billko wrote:

I have to say, it's a little like saying, "Everyone who isn't here please raise their hands".  😄  Unfortunately, i don't have anything meaningful to contribute.  😞

---

Yep. It seems when I started a 2 months ago my sales person started me down the NXG road. It seems most users have not embraced NXG. Many answers I get are from the LabVIEW perspective but they are more programming in nature so they translate. This is more of an IDE question. They just don't seem to translate as well.

[billko]

---

@flycast wrote:

---

@billko wrote:

I have to say, it's a little like saying, "Everyone who isn't here please raise their hands".  😄  Unfortunately, i don't have anything meaningful to contribute.  😞

---

Yep. It seems when I started a 2 months ago my sales person started me down the NXG road. It seems most users have not embraced NXG. Many answers I get are from the LabVIEW perspective but they are more programming in nature so they translate. This is more of an IDE question. They just don't seem to translate as well.

---

I really, really want to like NXG, but the combination of immaturity (maybe both NXG and myself) plus some design choices that I don't agree with has deterred me from using it for anything of even moderate complexity.  😞

[paul_cardinale]

This works for classic LV.

Fortunately, I don't know how to do anything in NXG.