When using the VI Server method "Vi Dependencies" it will not return non-vi dependencies such as XControls, classes (.lvclass, methods ARE reported) and so on.
How then, do we find these dependencies? Does at least adding the VI in question to an empty project and then getting the dependencies of the target work?
Yes, if you drill down through the dependencies of project, XControls will be found.
As the XControl is part of the front panel, a simple diagram "dependency walking" is not sufficient.
You can grab the front panel reference of the VI, get all controls and check for presence of an XControl instance (IsXControl?).
Using the VI Scripting node "Found Dependencies" on those instances will list the XControl name.
Norbert, which "Found Dependencies" are you referring to?
Do you mean fishing through each and every control on the FP, and for those which report they are XControls, then use the "Found Dependencies" on those controls?
Just want to make sure I understand.
You can run that property on any control. I tested this for arrays and a 3D Graph indicator. The 3D Graph results in the expected xctl name while the entries for arrays are empty strings.
But yes, essentially i recommend to call Found Dependencies only for XControls in order to reduce overhead.
On a side note, if an XControl is a dependency of a given VI, why does it not turn up in the dependencies list of the VI without having to dig deeper? OR .lvclasses for that matter.... If those would be returned, the whole thing would be a lot simpler.
Sounds like a feature request. The Get VI Dependencies method includes an exclusion text in its help:
This method does not return non-VI dependencies, such as project libraries, XControls, classes, and statecharts.
If you are using class VIs inside the VI, getting the class is rather "easy". However, things get tricky if you do not use methods of a class, but have class elements (e.g. front panel connection) in the VI.
What is the reason for looking into dependencies of a single VI without a project behind it?
[...] Does at least adding the VI in question to an empty project and then getting the dependencies of the target work?
As Paul already mentioned, project dependency walking is possible. You should use recursion to catch all nested dependencies as well if necessary.
You've hit the nail ont he head, classes, libraries and XControls will not be found if methods are not used.
So basically, in order to get the full dependency list, we NEED to interrogare each FP item and EACH BD item in order to find possible classes, XControls and so on......
Ugh, I was hoping the "Get Dependencies" method would spare me all of that. I can just as well ignore the method entirely and parse myself.
We are working with projects, but I need to know the dependencies of individual items within the project and I wanted to avoid having to put each VI in an empty project in order to get the full list of dependencies (They can't remain in separate projects because we want to do some dynamic re-linking of items.).
If the information is used for users (human 'readable') only, i think that creating a VI hierarchy view should be sufficient.
You can create it by using Application method "Get VI Hierarchy Image Scaled".