LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
_carl

"Find All Instances" of a VI should be just as capable as "Find -> Callers"

Status: New

I often use the "Find All Instances" option from the right-click menu when clicking on a VI's icon to find all callers of that VI. However, it regularly comes up with fewer hits than the "Find Callers" option. In this case, it came up with 0 hits:

 

_carl_1-1761599933386.png

 

However, if I navigate to the VI in my project (ctrl+shift+e) and then right-click on it and select "Find -> Callers" it will actually find the callers:

_carl_2-1761600292434.png

 

I've never understood this discrepancy, and I see it regularly. Perhaps this is more a bug than a feature request -- but I do feel that if these callers are consistently findable from through one of these mechanisms, they should be consistently findable through both.

 

Note: in the case above, if I do open the VI (after finding in using "Find Callers"), it will then be found if I "Find All Instances...".  But if I close the VI, it's no longer found using "Find All Instances".

 

 

4 Comments
raphschru
Active Participant

The difference is that "Find All Instances" requires the VIs to be in memory to be able to search their front panel and block diagram for instances of controls/subVIs/nodes. If you just open your top-level VI(s) before doing the search, it will load the whole call hierarchy and you will find all instances as expected.

 

"Find > Callers" however works regardless of the "in-memory" state of the VIs because it just reads the links between the VIs without digging into their front panel or block diagram.

 

If "Find All Instances" loaded all VIs contained in your project for you before doing the search, then unloaded them after the search, it would be much slower each time.

 

To be clear, I would also like that "Find All Instances" works for all VIs in the project, as you requested in your idea, but I am just pointing out that it could drastically affect search performance.

wiebe@CARYA
Knight of NI

""Find > Callers" however works regardless of the "in-memory" state of the VIs because it just reads the links between the VIs without digging into their front panel or block diagram."

 

Sadly, Find>Callers won't find SubVI instances in disabled cases of VIs that haven't been loaded (opened?) yet... It will find those instances after you manually located them once. *Sigh*

raphschru
Active Participant
wiebe@CARYA wrote:

Sadly, Find>Callers won't find SubVI instances in disabled cases of VIs that haven't been loaded (opened?) yet... It will find those instances after you manually located them once.


"Find > Callers" searches for, well, the callers 😀, not subVI instances on the diagram like "Find All Instances" or the "Find" (Ctrl+F) tool. If you disable a subVI in a diagram, then you are technically not calling it anymore.

 

I would be more concerned about the inconsistency of results that you are describing depending on whether or not "you manually located them once". I could not reproduce that behavior with a simple example though.

wiebe@CARYA
Knight of NI

> If you disable a subVI in a diagram, then you are technically not calling it anymore.

 

Although a disabled case guarantees the VI isn't called, a simple case structure could have that effect too. In fact, a case structure can cause the SubVI call to be removed by the compiler. In my opinion the find shouldn't be too concerned about this and simply return all VIs that depend on the subVI. "Callers" is technically a poor choice of word...

 

>I could not reproduce that behavior with a simple example though.

 

I haven't tried to make a simple example. I've seen this a lot in real project though. Open the project (no VI), find callers has n results, locate the disabled SubVIs, find callers find n+1 results. Most of my VIs are in classes, so that might be a factor. Although that forces the VIs to be loaded in memory, it might make the find a bit too lazy, assuming all dependencies are determined because the VI is in memory.