Resolve conflicts - Missing file problem

[matt.baker]

Any ideas on how to resolve the conflicts below?

I've tried:

Unloading the broken VI and reloading it with the correct path.

Finding callers, but that just shows a single top-level VI with no indication of which part is linking to the missing file. This was while the missing file was "loaded" so I assume that it must be a problem in that VI.

Save All.

[Yamaeda]

You need to open some or all of those listed VI's, and correct the linkage. 😕 Hopefully, if they're in a library it should be enough to correct one and just open the others, then save all.

/Y

[Bob_Schor]

While I love the LabVIEW Project, and use it all the time, there are those odd moments when we do something and the Project gets all messed up.  A frequent way this happens is that we move files around outside the Project, rather than open them in the Project and do a Rename (which, as we all know, is the "modern" way to say "Move" -- don't get me started ...).

Sometimes, however, that's not enough.  Yamaeda is right -- find the Caller, open it, look for the "missing VI", and replace it with something (or delete it, altogether).  Another thing to do that, on occasion, will work is to open Dependencies, look to see if the item in Conflict is listed there, right-click and see if you have the choice to "Replace with Item found in Project".  Sometimes it is just a wonky "name" problem.

These glitches can usually be fixed, though it sometimes takes going through them and fixing them, one by one.  Despite these occasional problems (usually brought on by my own carelessness), I still always develop in the context of a LabVIEW Project (unless it is a little test VI I'm writing to answer a question on the Forum ...).

Bob Schor

[matt.baker]

Thanks for the suggestions.

It's definitely from moving files. We have a network share that one developer uses and I sync with this locally which means that when I open it LabVIEW has to try and resolve the paths. The folder structure is the same, just the top-level path is different. 95% of the time LabVIEW successfully resolves the paths when opened on my machine locally.

In this case the file that is missing never existed (sort of), it should be C:\Matt\AGD LabVIEW\Libraries\Source\VISA comms\VISA comms.lvclass.

LabVIEW has got confused and is trying to link to a file which doesn't exist C:\Matt\AGD LabVIEW\Projects\Libraries\Source\VISA comms\VISA comms.lvclass.

The replace with option is disabled unfortunately.

With the correct class loaded into memory, selecting Find -> Callers shows loads of items as expected (files linking to the correct path). If I manually unload this, attempt to load the missing class and list callers again it only shows a single file.

However, when opening this file nothing is broken and still runs.

I'm unable to find any missing VI's in the single file that references the missing item, so I'm assuming its related to a constant or control using a typedef. The only way I can think of finding this is by traversing through all elements using scripting, both on the BD and FP and checking the typedef path to make sure it doesn't contain AGD LabVIEW\Projects\Libraries.

Video attached or https://drive.google.com/file/d/1896E2SFi1hPU1R8evdqEtuEOSTzjyXd8/view

[matt.baker]

Created the following VI, but it didn't find anything that references that broken class. Any more ideas?

[matt.baker · Accepted solution]

Found a missing VI that was in a diagram disable structure. Now fixed.

The reason the scripting VI did not find it was because I wasn't checking the MissingVIPath property for SubVI types.

[Hooovahh]

Glad you solved it, and good idea checking the Missing Paths.  But in the future there are several improvements you can make to your traversing code.  First the option of Other in the Traverse for GObjects is intended for when you provide the other reference type to traverse from.  So for instance you might want to traverse from a specific pane, well then you would choose Other and provide the reference to that pane.  Choosing other and then not providing a reference will likely generate an error and isn't really useful in this case.  

Beyond that you are clearly just looking for Constant, Control, and a SubVI.  Each of these can only exist in a Front Panel or a Block Diagram but not both, so searching first for all Front Panels, using the Control Class Name, then Block Diagram twice once with Constant, once with SubVI class names will likely make your code run much faster.

[matt.baker]

Thanks Hooovahh.

Some very good points!

I did encounter errors when I  was using "other". I must admit, I just threw it together without reading the function's help file and hoped for the best in this case, also seem to have have found a potential bug with the missing paths property when used on dynamic dispatch VIs.

I'll be sure to take that into account in the future, again it was just thrown together 😀.

I've been doing some work with the project provider framework recently so will use it on that.