Control in dependencies claims to be used by other VIs, but it isn't...

[Sebastian.Weber]

Hi!

I've a weird problem, here...

In my project, there's a control in the dependency folder of the project explorer, which is marked as "missing". That file indeed does not exist.

Usually, I'd expect some broken VIs due to the missing dependency, but there's none.

Rightclick -> "Why is this item in Dependencies?" shows a list of several VIs of the project. But none of them is broken, I can even execute them.

I examined one very simple VI of those, which has just one typedef cluster as dependency. When I remove this cluster, the control does not claim that this VI depends on it.

Alternatively, I can disconnect that cluster from its typedef, and consecutively all nested typedefs inside. Eventually, the control also dies not claim that this VI depends on it. BUT: The control was none of typedefs.

So, how is it possible that there's a control automatically loaded into the dependencies, which claims that several VIs depend on it, but none of the VIs know about that and simply run?

[Darren]

This happens to me quite often when I rename/move/whatever source files and the LV Project window gets confused about old names vs. new names (probably due to a bug in LabVIEW with storing linkages within source files). Anyway, the manual process I use to fix it is to open each of the VIs that the project window claims depends on the missing file. Once all of them are open at the same time, the missing file disappears from Dependencies, I save all the open VIs, and the problem goes away.

[Sebastian.Weber]

Hi!

Sonds reasonable. I also have the impression that LV stores a list of dependendy with each VI, and this list sometimes gets corrupted, not cleaned up, or whatever. I've some VIs that make LV load random additional files, though I don't see any reason for it.

So, that list is cleaned up when you open that files. However, that does not work here, the dependency remains although none of the listed VIs really depend on it.

[Darren]

When you have all the VIs open, you can hold down the Ctrl-key and click the Run arrow of each VI, which will force each VI to recompile, then save each VI after. That might "fix" the erroneous dependency issue as well.

[Kyle97330]

It's entirely possible that this dependency isn't made up but the link is "weak"...

It could be that somewhere in your code is a type definition that is a member of a library or class.  Loading that triggers LabVIEW to load the remainder of the library/class.  Then, somewhere inside that library or class, there's a VI that has a diagram disable structure in it, and somewhere in one of the disabled cases is a strictly defined connection pane reference, and inside that reference there's a link to that missing type definition.  Or something else similarly obscure...

There's a private Application method, "Linker.Read Info From File", that if you analyze its output can sometimes better trace what is causing something to be linked as a dependency.... if you're really desperate (and the forced recompile doesn't resolve it).