Jump to content

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


Recommended Posts

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

Link to post
Share on other sites
  • 6 months later...

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 9 months later...
"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)

Link to post
Share on other sites

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.

Link to post
Share on other sites
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.

 

post-17237-0-85660100-1358974141_thumb.p

Link to post
Share on other sites
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?
Link to post
Share on other sites
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.

Link to post
Share on other sites
  • 9 months later...

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 2 months later...
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.

  • Like 1
Link to post
Share on other sites
  • 1 year later...

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.