Filter dependencies from "Find Items with No Callers"

[dan_u]

"Find Items with No Callers" could be a useful function on the project, but currently most items it reports are in Dependencies. Why is an item even under Dependencies if there is no caller? It seems if I call one function from an .lvlib the whole library is in dependencies, and all other functions have no callers. This floods my "Find Items with No Callers" window with useless entries.

Suggestion: add option to hide items from dependencies in the "Find Items with No Callers" window (or even hide them by default).

[altenbach]

This has been discussed elsewhere long ago. I don't think anything from vi.lib should even show up in this list.

[dan_u]

That would be fine with me as well. An option to hide the vi.lib from the Dependencies (just like in the VI Hierarchy) would also be nice.

[dan_u]

Also, the "Find Items with No Callers" dialog should not be modal. I want to check an instance in the project/code and then come back to the dialog without having to open it again.

[dan_u]

Sorry for multiple posts.

I discovered recently that the "Find Items with No Callers" is not reliable. In my project it lists some VIs that are definitely used (as subVIs, no dynamic calls) by other VIs within the same project, but are listed as item with no caller. Right-clicking the VI and selecting "Find Callers" also says no callers found. Opening the caller and selecting "Find Callers" on the SubVI again will then find the caller.

If this function is not reliable it is of limited use...

[AristosQueue (NI)]

dan_u: I use the function frequently and know of no bugs with it. If you have found such, please post your hierarchy to an AE so they can investigate the bug.

[dan_u]

I can assure you there is a bug. Maybe related to separating source from compiled code, but I'm not sure. If I resave the affected VI combination to a new location the issue disappears, so I guess it would also disappear when saving the VIs (without compiled code) on a new machine, forcing a recompilation.

It's worrying, maybe also related to the bug with RT deploys (does not deploy modified SubVIs, still running the old code).

[AristosQueue (NI)]

> Maybe related to separating source from compiled code, but I'm not sure. 

Doubtful... I use that option exclusively. But I believe you when you say you've found a bug.

Please do contact an AE and open a service ticket with your code so they can investigate.

[fabric]

I have experienced similar issues. 

Possibly related to items showing up in "Dependencies>Items in Memory" when they should actually just show under "Dependencies". I get that a lot too.