From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Bob_Schor

Utility to disassociate VI from Library (.lvlib)

Status: Declined

Functionality already present in LabVIEW

I was trying to isolate two versions of code by putting them in a "Version 2.0" and "Version 2.1" library, and then (at run time) calling the appropriate analysis routine from the "correct" Library based on values stored in the data.  In the process, I managed to corrupt the .lvlib file, and (because I didn't know better) tried to "correct" this error by deleting the .lvlib file.

 

What that left me with was a file, formerly in the library, that I couldn't open without LabVIEW complaining bitterly that it could not find "Untitled Library 1.lvlib".  In addition, I could not even create a new Project and "Add" anything without such an error message appearing.

 

After a few weeks of struggle and consultation with NI Support, we found part of the problem -- the file that was formerly in the (now-deleted) Library had "hooks" to the Library embedded in its header.  Since this is in a proprietary (NI) binary format, I would like NI to provide a utility that can open a VI (or anything else that can be embedded in a Library) and remove the "hooks" that associate it with a particular .lvlib.  If this function were a LabVIEW function, then the user could write a utility using this function to apply it to a file, a folder, or a directory tree, as the situation warranted.  This would allow large VIs "corrupted" by being placed in, and improperly removed from, a Library to be returned to a stable, non-Library, state.

 

Bob Schor

4 Comments
crossrulz
Knight of NI

File->Disconnect From Library

 

Yes, you currently have to do it on an individual file basis, but the capability is there.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
tst
Knight of NI Knight of NI
Knight of NI

And it also already exists as a method on the VI, so you can easily create a tool to do this programmatically for a bunch of VIs.

 

Also, just to be clear, those "hooks" are not there by accident. The library-VI relationship is two-way by design. Each library knows which VIs it owns and each VI knows which library owns it. There are good reasons for this design.


___________________
Try to take over the world!
Bob_Schor
Knight of NI

I agree, and "withdraw" this suggestion.  I'm new enough to Libraries, and the information is difficult enough to ferret out, that it wasn't until after I posted this, while looking up clues on how to "clone" a Library (make a copy, called Library 2, of Library 1, with the idea of modifying VIs in Library 2 to be the "second version" or for the "second Instrument") that I stumbled upon the "Disconnect from Library".  I just tested it on one of my "broken" VIs, and it does, indeed, fix it.  I'm perfectly capable of writing the Directory Traversal routine that can do a whole-scale Disconnect, now that I know about this Property.

 

Bob ("Always Learning") Schor

Darren
Proven Zealot
Status changed to: Declined

Functionality already present in LabVIEW