The Project Dependencies List should be smart enough to not list all instances of a Polymorphic DAQmx VI

[Broken_Arrow]

Once I set the Polymorphic DAQmx Vi to (for instance) AI Current, why is DAQmx Create Channel (CO-Pulse Generation-Freqiency).vi and a hundred others shown in Dependencies? I stopped counting at 200 DAQmx VI's in my list, and I'm just using 12 VI's.

 

An alternative to getting the Project list working right would be the ability to convert a Polymorphic DAQmx VI to it's selected VI.

[elset191]

See here for an idea that is probably closely linked to this one.  There is a lot of discussion too

[Broken_Arrow]

Yep elset, I Kudo'd that a while back. I'm interested here in keeping my Dependencies list cleaner, but one implementation may fix both hierarchy and project list issues.

[AristosQueue (NI)]

> An alternative to getting the Project list working right would be the ability to convert a Polymorphic DAQmx VI to it's selected VI.

I agree that this could be easier. Probably worth submitting as a separate top level Idea. In the meantime, you can drop the specific VI instead of dropping the poly VI, or you could drop the poly VI, pick the instance you want, and then use Replace.

As far as "fixing the dependencies" is concerned, I still think the Dependencies list is correct as written. If any one of those VIs is missing on disk, the poly VI will be broken and your app will then be broken. You do have a dependency on all the VIs listed. They (and their subVIs) can create cross links. One of the major flaws of LV 8.0 was that the Dependencies section wasn't comprehensive. Now we've fixed that, and a lot of features now work much better with that change.

[Brian_Powell]

What if the PolyVI was listed as an unexpanded item with a "+" next to it, and the child VIs were shown when you clicked the "+"? This way, all the dependent VIs are technically in the list, but aren't bloating the UI unless you ask for it.

The VI Server methods that enumerate the dependencies could retain their current behavior, for compatibility.  (Or perhaps there's a clever way to get the Poly/Child relationship without confusing existing apps.)

What happens if a child VI is referred to from a PolyVI and directly from one of the end user's diagrams?  Should the child show up twice in this case, or only once?  Is there a clean solution to this?  Hmm.

[AristosQueue (NI)]

Brian: One problem use case: each of the instance VIs of the Poly VI is a member of a different class and/or library. That's something I've seen a few times in the last couple years. The member VIs would be listed under their respective libraries, not under the poly VI.

I don't think any change we make to the UI of the project would have any impact on any of the VI Server methods. I think there are only two... ReadLinkerInfo and Get VI Dependencies. We would still be including all the dependencies in ReadLinkerInfo and Get VI Dependencies is only for a single VI, not for a whole hierarchy.