Hot pink to show dependency

[FixedWire]

It can happen that a VI, or worse a typedef, gets inadvertently pulled into code from another library or class simply to reuse code.

Using "Why is this item in the Dependencies" isn't particularly helpful in a large project.

Could not the offending dependency be marked with hot pink or similar to using a breakpoint? Could the Breakpoint Manager be adapted to finding dependencies?

[wiebe@CARYA]

I'd open the dependency, and use find all instances.

[FixedWire]

Yes, that will help until an entire library gets sucked in because of one reused VI and you don't know which one of 749 VIs (or a typedef) in that library are the culprit. Depending on the way the code was written if that one VI that contains the dependency has a lot of code or states it'll take a while. Hence a more expedient solution is needed. Not sure how this plays out with larger frameworks & the new interfaces as I've not delved into this yet.

[JimKhertzian]

Right-click your library Using "Why is this item in the Dependencies" will lead you to the dependant VI should be enough to find the culprit.

[wiebe@CARYA]

Right-click your library Using "Why is this item in the Dependencies" will lead you to the dependant VI should be enough to find the culprit.

The point of this idea is that "Why is this item in the Dependencies" doesn't lead to the problem, only the VI that has the problem.

I actually agree, that this isn't helpful if the VI is non-trivial. It is enough to find the culprit, but I'd prefer not having to search myself.

[thols]

Come up with a better heading, make some fancy graphics that explains the idea and let altenbach post it 😀. That would generate some kudos.

I also find it frustrating that the VI is pointed out but not what in the VI that causes the dependency.

[wiebe@CARYA]

I think a moderator (or at least some moderators) can edit the post? I've seen images been added to ideas even after several pages of replies. I'm not sure how much goodwill one needs to get that done though. You'd probably need to address the right person. 

[drjdpowell]

"Why is this item in the Dependencies" is certainly something that desperately needs improvement.  Too often it acts to waste developer time as it provides too little info.

[wiebe@CARYA]

I don't really like 'something like a breakpoint\breakpoint manager'.

I'd prefer a 'find all dependencies' dialog. Like find all instances, that opens the VI (what we have now) and highlights the item (new).

The original idea is more focused on the problem, and only suggests a solution.

So should we kudo the original idea?

[FixedWire]

Thanks everyone for the input. There's enough pain in the community, not just myself, to warrant additional effort to formulate a solution.

"I'd prefer a 'find all dependencies' dialog. Like find all instances, that opens the VI (what we have now) and highlights the item (new)."

Spot on.

The idea of extending the 'find all dependencies' dialog to highlight where in the code the dependency is used may just suffice. Under the hood LV must create a list already so it should be possible to allow the user to navigate to the specific offending code.

[wiebe@CARYA]

"Under the hood LV must create a list already so it should be possible to allow the user to navigate to the specific offending code."

I'm afraid it isn't that simple. The list that LabVIEW has now is a list of VI dependencies, not a list of nodes (UIDs) on diagrams.

The dependencies are managed on a different level. Getting a list of UIDs might have consequences. For instance VIs need to be loaded, while at the moment they don't need to be. I'm not sure actually, but there will be consequences. As a LabVIEW developer, I'd sure have my reservations. But as a user, it's clumsy as it is. 

But, I'll kudo the idea. This deserves some attention.