Searching for all dll functions called in nested vi programs

[colorimeter]

I have a vi with many sub vi's. There is a .net dll library with different functions, and it is called in several instances in the code. I need to list all dll functions that the code calls, so I am trying to search for Constructor nodes and look at what functions they use. However sometimes the Constructor is disabled and I can't tell what dll function is called. There also seem to be other ways that the .net functions are called. 

What search approach will let me find and list all functions in the dll that the vi calls?

As you can tell, I'm a novice looking at code someone else wrote. 

[Kyle97330 · Accepted solution]

Is your main problem finding all .NET nodes period?  It sounds like it, because all Constructor nodes are .NET only, but the only way to search for other things turns up a lot of false leads, i.e. if you search for property or invoke nodes, you get a lot of results that are not .NET calls.

There's something called "VI scripting", which is a feature in the options menu that you can turn on which allows you to write LabVIEW code that analyzes and/or modifies other LabVIEW code files.  This is one way of doing it, but it's fairly advanced.  

Do you have LabVIEW Professional, or a different version?  If you have LabVIEW Professional, you could look into using "VI Analyzer", which is a toolkit you can get and use to scan all VIs in a given project.  It is mainly meant to look for potential problems with your code that you might not spot when checking it manually.  However, one of the tests it has is "Platform portability" (under General --> VI Properties, if you install it and are looking for the test), and that test is designed to look for any code which will fail if the VI is moved to MacOS or Linux, which will then flag any constructor, invoke, or property node as a warning.  If you install that and turn the "Maximum reported failures" way up (default is 5, you could change it to 100 or so just so it doesn't skip anything if you have a lot of nodes in one big VI) then you have effectively made something that will scan your whole project for constructor, invoke, and property nodes, but only .NET nodes.  You will still have to click on each one to go and see it, but it's at least a filter of some kind.

[colorimeter]

In one of the vis, I can see some .net refnums, but no .net dll functions seem connected to them. However in the Context Help for the .net refnum, there's a list of two long strings after Reference Out which could be functions in the .net dll that are called. Are they? I can't figure this out from the help.  

If not, I know somewhere this .vi uses functions in the dll, but there are no Constructor objects I can find. What other kinds of objects could be calling the .net dll functions besides Constructors?

By the way, I'm using Professional (32-bit LV 2017). 

[colorimeter]

I searched for Invoke modes, and this seemed to pull up all the instances where functions in the dll were called. Perhaps this was the coding style of the code author. The one trick is, I can only figure out how to Search for Invoke modes by finding one, selecting it, then doing Control-F. I am not familiar enough with the palette to find the Invoke mode. But that's a minor problem. Thanks for your help.

[rolfk]

It may be a language problem in you trying to explain what you are doing, but it sounds like you are misunderstanding how .Net is called in LabVIEW. 

A Constructor node is simply the equivalent to the .Net new operator in C#. It creates an object. Not all .Net classes need to be created. So called static classes are simply present in the assembly and can’t be instantiated. When one wants to call a method (function) of an object/class one uses an Invoke Node on the refnum. To access attributes of an object/class one uses a Property Node. That has nothing to do with a preference of the person writing the code but simply how one deals with .Net objects and classes in LabVIEW.

[colorimeter]

Thank you. This helps me feel confident that by checking all Invoke nodes, I found all the .dll functions called by this vi and its subvis.