Bug, or misunderstanding? Project incorrectly shows "No Callers"

[OneOfTheDans]

In a LabVIEW project, Find > Callers is extremely useful. But I found a case where it seems to be broken. Am I misunderstanding the tool? (the actor framework info here should be irrelevant).

• MyProj.lvproj
  
  • LibA.lvlib
    • Actor.lvclass <-- inherits from Actor Framework.lvlib:Actor.lvclass
      • Read Property.vi <-- dynamically dispatched data member access
  • LibB.lvlib
    • Actor.lvclass <-- inherits from LibA.lvlib:Actor.lvclass
      • Actor Core.vi <-- uses parent class's Read Property.vi on self

LabVIEW will tell me that Read Property.vi has No Callers. And that's not true. Is this a bug? I've seen it before on other projects, and just ignored it, but now I'm curious. This seems to be the case anytime a parent's methods are only used by subclasses.

[PiDi]

It searches for the callers that are loaded into memory. That means if you have no opened VI (only the project explorer window), you won't find any callers of any VI. This might not be always true, but let's take this as a basic rule. I think there are some more information on when VI is loaded and where not somewhere in the LV help, but I can't find it now.

[dan_u]

---

@PiDi wrote:

It searches for the callers that are loaded into memory. That means if you have no opened VI (only the project explorer window), you won't find any callers of any VI. This might not be always true, but let's take this as a basic rule. I think there are some more information on when VI is loaded and where not somewhere in the LV help, but I can't find it now.

---

That's not true afaik. This is the case for "Find all instances", which will only list the instances of a VI which are in memory. The project based Find > Callers should find all callers which are in the project, even if no VI is open.
I think it's the same bug I noticed in "Find Items with No Callers" (here).

[OneOfTheDans]

PiDi:

I think "Find > Callers" normally works the way dan_u described. Anyway, I tried keeping a caller (from a subclass) open while doing "Find > Callers" and it still showed No Callers. This is looking like a LabVIEW bug... 

dan_u:

You saw that bug a few years ago... did you ever get a resolution? Have you seen it in newer versions of LabVIEW too?

[OneOfTheDans]

Ok, I just created from scratch the scenario in my OP, and I can replicate the bug. I'm attaching the project here. Any ideas what's wrong? I guess I'm going to try contacting NI about this...

[dan_u]

As AQ proposed, I tried isolating the bug so I can send something to an NI AE, but whenever I saved a portion of our project into a new project the bug disappeared. So I could not create a test project where the bug is reproducible. And if it is not reproducible, then in my experience nothing will happen anyway (which I kind of understand...).

So I did not even report it, thus no resolution. I'm still working in LV2015 SP1, so I can't comment about newer LV versions. But at least other bugs which to me seem kind of related (e.g. incorrect deploys to RT, i.e. you modify a subVI of a RT VI, then deploy the main VI, but it still deploys the old version of the modified subVI) seem to be still in newer LV versions. 

[OneOfTheDans]

I'm glad to know you didn't report this. It would be sad if they knew about this for 2-3 years with no resolution . I just opened a support request, so we'll see what comes of it. Who knows, maybe this one will come down to user-error after all.

[Jacobson-ni]

It seems like the callers have trouble being found because the method is dynamic dispatch. If the method is static dispatch it can be found.

Things start to get really wonky when the method is dynamic dispatch. Let's say we have two classes Parent.lvclass and Child.lvclass (child inherits from parent). To complete the setup, create a dynamic dispatch method under parent and override it in the child class and have a static dispatch method in each class which calls this override-able method. If we search for the callers for the dynamic dispatch VI under the parent it will only find the parent's static dispatch VI. However if we search for the same dynamic dispatch method under child, it will find both callers.

I guess I'm not too surprised at this behavior because if a dynamic dispatch VI is on a block diagram, we can't say who's instance it will call during runtime.

[OneOfTheDans]

I can understand how dynamic dispatch complicates things, but to say there are No Callers is simply incorrect. At the very least, I'd expect the tool to show register callers against the most generic method. Beyond that, it might be appropriate to show a tree of potential callers, similar to when you double-click a DD method.

[Jacobson-ni]

---

@OneOfTheDans wrote:

I can understand how dynamic dispatch complicates things, but to say there are No Callers is simply incorrect. At the very least, I'd expect the tool to show register callers against the most generic method. Beyond that, it might be appropriate to show a tree of potential callers, similar to when you double-click a DD method.

---

Sure, not saying any of the behavior is correct, just suggesting why we might be seeing the behavior.