Project Dependencies, 'Find Items Incorrectly Claimed by a Library'

[MartinMcD]

Hello there,

All of a sudden when I open one of my projects it is including a whole list of classes from another project in the dependencies. When I remove the main vi then the dependencies list is cleared and when I use the 'Find Items Incorrectly Claimed by a LIbrary' function it agrees with me that all the included dependencies should not be there.

Does anybody know why this happens please? I am not deliberatley referencing any of the included files and they never used to be there, and I haven't changed the code.

Can anyone help please?

Thanks

Martin

[Aristos Queue]

"Items incorrectly claimed by a library" is perhaps a bad description. A better term might be "Items that are claimed by the library that do not reciprocate the claim".

These items are ones where the library has been saved to disk and records "the item at this path location is a member of me" but the items themselves (VIs or sublibraries) were saved not claiming to be part of the library --- they may claim to be part of no library or another library.

This sort of thing generally happens when you move files around on disk instead of inside LV or when you rename the library but don't save the VIs in the library. It can take a while to untangle.

[MartinMcD]

Thank you for that, I've resolved it now and I've learnt my lesson.

[todd]

How does one resolve this? I have a project in 2011 that claims all private data ctl files are incorrectly claimed by a library. Moving the classes out of and back into the lvlibs didn't help. Even making a new class in a new blank project doesn't work. Downloading 2011SP1 right now.

I only looked at "incorrectly claimed" because LabVIEW crashes every time I add a string control (or indicator) to an existing class' private data.

[todd]

I've tried a few things: removing all classes and methods from the library in the project viewer - then adding them back. Doing the same thing from a separate lvlib-only project-type window. The xml files look fine.

[JackDunaway]

"Items incorrectly claimed by a library" is perhaps a bad description. A better term might be "Items that are claimed by the library that do not reciprocate the claim".

These items are ones where the library has been saved to disk and records "the item at this path location is a member of me" but the items themselves (VIs or sublibraries) were saved not claiming to be part of the library --- they may claim to be part of no library or another library.

This sort of thing generally happens when you move files around on disk instead of inside LV or when you rename the library but don't save the VIs in the library. It can take a while to untangle.

 

 

Reviving a bit of an old thread... 

 

So when I click on the root project item and invoke "Find Items Incorrectly Claimed by a Library", it returns a list of hundreds of VIs, nearly all of which are in vi.lib. But a few dozen were in my codebase, and so I fixed them; fair enough. (The trivial fix is to manually drag offending members out of the library and then back in; a bit tedious for a few dozen items, but it could be automated through VI Server)

 

Just trying to learn more about this, so...

 

What is the benefit of resolving this 'condition'? What are negative consequences of not resolving this non-reciprocation? I have yet to run across any concrete problems caused by this condition, other than an icky feeling. (Case in point: vi.lib ships with many library members who don't acknowledge their ownership, apparently without problems)

[Aristos Queue]

Something is wrong with your library if you're getting hundreds of hits with that operation from vi.lib... or something is broken with that function.

This feature finds items that will be broken when they load into memory because the library claims them but they do not reciprocate the claim. The library somehow thinks all of those VIs are its members. Weird.

[JackDunaway]

Something is wrong with your library if you're getting hundreds of hits with that operation from vi.lib... or something is broken with that function.

This feature finds items that will be broken when they load into memory because the library claims them but they do not reciprocate the claim. The library somehow thinks all of those VIs are its members. Weird.

 

So, there's definitely something wrong here. My sanity says 'thanks' for this info.

 

Attached is a snippet that shows just the first few hundred 'issues' -- feel free to run it yourself on your own project; the values from my run are set as default data on the indicator. And again, 'issues' notwithstanding, nothing in the project is broken.

 

[Aristos Queue]

So, there's definitely something wrong here. My sanity says 'thanks' for this info.

It works fine for me... only returns things that are really problems. Inside the project, open one of the specified VIs... does it ask to be disconnected from the library? Open the library... does it show yellow triangled items?

[JackDunaway]

It works fine for me... only returns things that are really problems. Inside the project, open one of the specified VIs... does it ask to be disconnected from the library? Open the library... does it show yellow triangled items?

 

No -- again, I see *no* negative side effects, no yellow warnings, no linker/compiler errors... let's take this offline, and I can report back to this thread if we learn anything of interest.

[Thoric]

Jack, did you learn anything or have any further comment?

 

I see this too, and there are no apparent side effects, the libraries are happy, and the classes are happy. But still I get dozens of items listed as 'not belonging' in my library. Mainly class private data ctl files, which clearly can't be moved out and back into a class to fix the association.

[JackDunaway]

Growing up, did you hear the kindergarten joke, "your epidermis is showing!"?

 

Live and learn -- we all come to realize 98% of the time it's fine to have some epidermis showing, and that other 2%, you're going to have much earlier and much more distinct warning signs.

 

Thoric, apologies for lack of a better response, but I've just stopped paying any attention to the report provided by "Find Items Incorrectly Claimed by a Library", having seen zero Real Problems in either dev or deployment environments. The compiler warns of all Real Problems.

[Thoric]

I'll relax then and ignore this. Thanks for taking the time to reply! 

[JackDunaway]

I can report back to this thread if we learn anything of interest.

 

I stumbled upon one resolution to this issue (air quotes, "issue") recently:

1. Restart LabVIEW
   
2. From the Getting Started Window, select "Tools >> Advanced >> Clear Compile Object Cache..."
   
3. Clear both User and App Builder cache (my hunch is that the App Builder cache is not necessary; but why not)
   
4. Restart LabVIEW
   
5. Open the guilty lvproj
   
6. Mass compile the project root
   
7. Now, "Find Items Incorrectly Claimed by a Library" -- no more spurious ownership issues
   

Anecdotally, it's not sufficient to clear the cache while the project is loaded (or, perhaps it might be sufficient with a subsequent reboot). Your mileage may vary.

[Reimar]

JackDunaway, Posted 22 January 2014 - 05:50 AM

Can you explain in detail Point 3 of your recipe: How to Clear both User and App Builder cache?

[hooovahh]

Can you explain in detail Point 3 of your recipe: How to Clear both User and App Builder cache?

After launching the Clear Compiled Object Cache from Tools >> Advanced >> Clear Compiled Object Cache... a window appears  with a listbox showing two items, User and Application Builder.  By default both are already selected just click Delete.  If you only want to delete one select that one, then click Delete.

[X___]

On 1/21/2014 at 7:50 PM, JackDunaway said:

 

I stumbled upon one resolution to this issue (air quotes, "issue") recently:

1. Restart LabVIEW
2. From the Getting Started Window, select "Tools >> Advanced >> Clear Compile Object Cache..."
3. Clear both User and App Builder cache (my hunch is that the App Builder cache is not necessary; but why not)
4. Restart LabVIEW
5. Open the guilty lvproj
6. Mass compile the project root
7. Now, "Find Items Incorrectly Claimed by a Library" -- no more spurious ownership issues

 

Anecdotally, it's not sufficient to clear the cache while the project is loaded (or, perhaps it might be sufficient with a subsequent reboot). Your mileage may vary.

This actually doesn't work as a general solution (one exception is enough to invalidate the rule, and I just experienced it).

However, as stated before, I believe that as long as they don't break the code, LabVIEW's compiler hallucinations can be ignored.