Lint Filter fails with LV Classes

[CoastalMaineBird]

LV2013, LVRT 2013, Win7

I'm working on a large (1600+ VIs) project, for some years now.

A long time ago, I created a "Lint Filter" program.  Here's what it does:

1... Make a list of all files in all LLBs in the project folder and subfolders.

2... Read an EXCLUSION file, and remove VIs specified there from the list.

3... Open all MAIN vis for the programs (one by one).

4... Remove this VI from the list.

5... Find all subVIs called by this main VI. Remove THEM from the list.

6... Find all subVIs called by THOSE subVIs.  Remove THEM from the list.

7... Repeat 3-6 until all VIs are covered.

Whatever is left is "Lint" - VIs that have no callers.  If it's a dynamically called VI, I put it into the EXCLUSION list and run again.

The point is to discover false starts, and VIs I created but didn't end up using.  I can then delete those and keep the code free of lint.

That all worked just fine for years, until I started to use Objects (LV Classes).  For the last month, I've been including a parent class and severel descendants in the project.   

The project is working.

However, it generated a lot of lint.  Some of the old code was replaced, and I made some false starts, so there are VIs not used.

The trouble is - the Lint Filter now reports over 200 lint VIs, some of them I know are really used. (If I delete one, the main VI is broken).

I've traced the problem down to the fact that Classes seem to be invisible.

Here is part of the code that chases the VIs and subVIs, etc.:

The problem is - the CALLEES output from that Property Node does not list any LVCLASS items, or any VIs that take a CLASS input.

Even a simple test case, with a CLASS constant and a CLASS VI, will not show up.

Any normally called VI is in the list, but if it's related to a class, it's forgotten.

Anybody have ideas on how to make the Lint Filter work in this case?

[CoastalMaineBird]

What does it mean that the property node is RED-colored in the above diagram?

If I remove the CALLEES property from that list, it turns YELLOW.  But I cannot get CALLEES back - it's not available.

Is that a deprecated property?

[Gregory]

The red property node is for a deprecated property, I'm sorry I cannot help with the rest.

[Intaris]

There's an Invoke Node "Get VI Dependencies".  It looks like this might be replacing the old "Callees" property.

Scratch that, documentation says it doesn't return classes......

Hmm, maybe you need to slap the VI into a project and then read out the Children from the project Item.... Sounds like a real PITA to be honest.

[Intaris]

Sorry, you would need a "TargetItem" (My Computer) and then access the Dependencies property.  Still a PITA though.

[CoastalMaineBird]

Sorry, Intaris.  Your scheme doesn't work.

I did a recursive chase thru the Dependencies tree, folllowing the OWNED ITEMS list.

It comes up with all sorts of useless crap (see attached pic - NONE of that is in my program), including DLLs for weird topics, but still shows not one class.  Not even one.

[CoastalMaineBird]

So, here's the code for two items:

--- RUN MODULE, which is the connection between the "regular" LV code and the OOP code

--- MODULE, which is an LV CLASS, and has several dynamic dispatch methods it calls, depending on the instance type of MODULE.

If I ask for the CALLEES of RUN MODULE, I get this.

Notice that it ignores the RUN MODULE.vi, and all the individual MODULE instances.

If I skip ahead and ask for th CALLEES of the MODULE.vi, I get this:

Notice how it ignores the methods that MODULE calls.

So, how do I programmatically trace these connections?

[CoastalMaineBird · Accepted solution]

Tech Support has come through (Thanks, Chris!) with an answer:

Given a VI Reference, there is a method (invoke node) called GET VI DEPENDENCIES that can be used.

There are all sorts of options, one of which is to INCLUDE ALL OVERRIDES.

I suppose that will still leave some override that I wrote, but never actually call.

Still, it's a big step in the right direction, and it's a LOT faster than traversing the chain myself.

[CoastalMaineBird]

Intaris, you were on the right track with the GET VI DEPENDENCIES idea, but you scratched your own idea, and I didn't pursue it.

It dosn't return LVCLASS items, but it DOES return class methods, including all overrides, if desired.