Project cleaning in LV8.6

[_Y_]

I encountered a problem when tried to clean an overgrown Project in LV 8.6.1.

Removal of project members does not usually cause any problem. In some cases the removed members are not forgotten. They simply go to Dependencies. This is justified if remaining members call the removed vi-s.

However, in some cases, members of Dependencies have no callers (the pop-up menu Find->Callers results in No items were found.). If I delete the corresponding files, conflict signs are displayed. The project is fully functional in all cases.

I tried to remove the corresponding line(s) manually from the lvproj file (that is an XML file). The line(s) reappear if the project is opened and saved again.

It seems there is something like "hidden callers" in the project.

Does anyone encountered and solved the problem? If so, please advice how to remove such unused dependencies. Thank you.

Edited August 25, 2009 by _Y_

[Val Brown]

I hadn't noticed this behavior in the past but now I'm encountering something very similar in LV2009. I have a project that looks for a VI during a build but that VI can't be found anywhere in the VIs OF the project. It's very, very curious and I have NI working with me on it.

[Daklu]

I've run into this quite frequently. In every* case it's because there was something in my project that still depended on the item I removed. Usually I'll find the offending dependency in a diagram disable structure or buried somewhere in a case structure.

Unfortunately Find->Callers is not a reliable way to find out if your project depends on a given item. Ironically the best way to see if you have a dependency is to remove the item from the project and see if it shows up in the dependency section. I've learned not to delete items with the hope the problem will go away. It doesn't--it just gets worse.

If I really can't find the dependency I'll close the project, rename the file I want to remove, and reopen the project. The vi that is loading when the browse dialog pops up is the one that has the dependency.

(*The one exception is if the removed item shifts into the 'Items in Memory' subfolder. In those cases your project doesn't depend on the removed item, but you have a non-project vi open that does depend on the removed item.)

[gb119]

I've run into this quite frequently. In every* case it's because there was something in my project that still depended on the item I removed. Usually I'll find the offending dependency in a diagram disable structure or buried somewhere in a case structure.

Unfortunately Find->Callers is not a reliable way to find out if your project depends on a given item. Ironically the best way to see if you have a dependency is to remove the item from the project and see if it shows up in the dependency section. I've learned not to delete items with the hope the problem will go away. It doesn't--it just gets worse.

If I really can't find the dependency I'll close the project, rename the file I want to remove, and reopen the project. The vi that is loading when the browse dialog pops up is the one that has the dependency.

(*The one exception is if the removed item shifts into the 'Items in Memory' subfolder. In those cases your project doesn't depend on the removed item, but you have a non-project vi open that does depend on the removed item.)

The really frustrating one I've encountered is when a class object has gotten saved with a child class instance as the default data. Sure the class icon on the block diagram shows up with a black border - but is it a black border because the class is the correct type but with non-default data, or is it black bordered because it's got a child class on it ? And other than opening each vi which uses a class and looking at its front panel to check for black borders, how the **** am I supposed to find which vi is keeping my child class in memory ?

The real problem with this comes when the vi holding the child class in memory is a mehtod vi of the parent class and the child class itslef is broken. That makes the parent class broken and every single child class of that parent is thus broken as well.... you can't simply unload the really broken child class because you can't easily track its dependency, fixing the breakage might not be easy if this is a child class that is under development...

[_Y_]

...diagram disable structure...

Thank you for the idea. However, in my case, the problem was more complicated.

Seems, Find->Callers do search the diagram disable structures. At least, it pretends to do so.

So far as the project could not find the deleted members, corresponding calls were automatically replaced in the diagrams with "lovely" grey-question-mark-nodes. Find->Callers does not search for them. As these nodes were in disabled cases no error appeared.

I had to search all diagram disable structures in the project (automatically), open each disabled case (manually), and look for these question-mark-nodes (visually).

PS: More tests have shown that the problem does not appear every time when a call to deleted vi is hidden in a diagram disable structure.

Edited August 26, 2009 by _Y_