Showing results for 
Search instead for 
Did you mean: 

XControl as dependency

I've just looked at the possibility of going the "New project with a single item" route and have encountered a weird behaviour.  Seems like a bug, but maybe I'm doing something wrong.


Object Dependencies.png


If I don't have any probes placed on a wire after the "Refresh dependencies" step, the first element of the "Owned Items[]" Array gives an error. Name and TypeString are both empty for this entry (Which APPEARS to be a refnum (not zero) ).  If I add a probe, then it works fine.  I tried placing an "Always copy" but that didn't help.  Hence my "Merge errors" instead of simply wiring up the error terminals.

0 Kudos
Message 11 of 14

@Norbert_B wrote:

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".


No, it's not meant for human consumption.  It's meant to do an automatic de-tangling of our software which currently is a monolithic gargantuan.  I need to be able to find ALL dependencies programmatically of a few thousand items, cross-correlate and work out a path to structure them differently.  Lots and lots of work, but technically it should be do-able (Bugs and LabVIEW idiosyncrasies aside).  Target is to move from a relatively un-modular structure to Lvlib and then to a hierarchy of PPLs.

0 Kudos
Message 12 of 14

What happens if you save the dummy project before refreshing the dependencies?


CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 13 of 14

Makes no difference.  First entry for some reason always throws an error.  Second entry is actually "vi.lib" which, when expanded in the Project view is actually the first visible item.  Seems like there's an item at the beginning of the array which doesn't belong there.

0 Kudos
Message 14 of 14