LabVIEW Libraries lvlib

[Dan Bookwalter N8DCJ]

I have never used them before , I have been reading about them lately...

is there anyone who uses them extensively who would be willing to schedule a phone call to discuss/inform me more about them...

it is too much to type out everything etc...

if you are willing to , I guess, send me a message on here and we can go from there...

Regards

Dan

[Rolf Kalbermatter]

On 4/4/2025 at 12:38 AM, Dan Bookwalter N8DCJ said:

I have never used them before , I have been reading about them lately...

is there anyone who uses them extensively who would be willing to schedule a phone call to discuss/inform me more about them...

it is too much to type out everything etc...

if you are willing to , I guess, send me a message on here and we can go from there...

Regards

Dan

Have you used LabVIEW classes? A LabVIEW Library is in many ways similar except that you do not have methods and properties but simply only functions (a sort of method) in them, and yes of course no private class data.

You can set functions to be private, public or community. Obviously there is no protected type function. 

Edited Thursday at 11:05 AM by Rolf Kalbermatter

[ShaunR]

There isn't anything really special about lvlibs. They are basically containers with a couple of bells and whistles. If you look at them with a text editor you will see it's basically a list of VI's in an  XML format.

The main reason I use them is that they can be protected with the NI 3rd Party Activation Toolkit. A secondary reason I use them is for organisation and partitioning. It would be frowned upon by many but I use lvlibs for the ability to add virtual directories and self populating directories for organisation and contain the actual VI's in llb's for ease of distribution. 

I don't see them as a poor-mans class, rather a llb with project-like features.

Edited Friday at 08:31 AM by ShaunR

[Rolf Kalbermatter]

On 4/11/2025 at 10:21 AM, ShaunR said:

I don't see them as a poor-mans class, rather a llb with project-like features.

I didn't say they are a poor mans class, just that they are similar in several ways. 😁

The entire low level mechanics underneath are very similar, the interface provided to the user is somewhat different.

Classes can have private data, libraries not.

Libraries are the pre-request to creating packed libraries, or as you found out to use the 3rd party Activation Toolkit.

They both have their use cases that are distinct from each other.

Edited Saturday at 02:28 PM by Rolf Kalbermatter

[ShaunR]

On 4/11/2025 at 11:19 AM, Rolf Kalbermatter said:

Libraries are the pre-request to creating packed libraries

*prerequisite.

Packed libraries are another feature that doesn't really solve any problems that you couldn't do with LLB's. At best it is a whole new  library type to solve a minor source code control problem.

Edited 19 hours ago by ShaunR

[Rolf Kalbermatter]

5 minutes ago, ShaunR said:

*prerequisite.

Packed libraries are another feature that doesn't really solve any problems that you couldn't do with LLB's. At best it is a whole new  library type to solve a minor source code control problem.

Well, except that LLBs only have one hierarchy level and no possibility to make VIs private for external users.

I do feel strongly about packed libraries being a potentially good idea with many limitations that I think were not fully thought out.

- Version resource to have some control what version a packed library is? Tacked on by wrapping the proprietary archive format into a PE file and storing it as a custom resource in the PE file. And of course only under Windows, sorry Linux and Linux RT users, we forgot about you.

- And the project environment is terrible in supporting them, as LabVIEW does not isolate packed libraries into their own application context. A PPL loaded into one application context, contaminates the entire LabVIEW memory space with its symbols and trying to load the same PPL but compiled for a different architecture into a different application context (RT target for instance) just messes up your project and sometimes beyond repair. And this is even so insane that if you load two projects separately at the same time with the same PPL with different architecture, you just managed to mess up both projects equally! Why does (almost) everything properly observe application context isolation except PPLs?

[ShaunR]

3 hours ago, Rolf Kalbermatter said:

Well, except that LLBs only have one hierarchy level and no possibility to make VIs private for external users.

You actually have 2 levels with LLB's (semanticly) and that's more than enough for me.

I also don't agree with all the private stuff. Protected should be the minimal resolution so people can override if they want to but still be able to modify everything without hacking the base. This only really makes sense in non-LabVIEW languages though so protected might as well be private in LabVIEW. And don't get me started with all that guff on "Friends" 

But in terms of containers, external users can call what they like as far as I'm concerned but just know only the published API is supported. So making stuff private is a non-issue to me. If I'm feeing generous and want them to call stuff then I make it a Top Level vi in the LLB. Everything else is support stuff for the top level VI's so call it at your peril.

I still maintain PPL's are just LLB's wearing straight-jackets and foot-shooting holsters. 

[Rolf Kalbermatter]

4 hours ago, ShaunR said:

I still maintain PPL's are just LLB's wearing straight-jackets and foot-shooting holsters. 

The straight-jacket should take care about shooting in your own feet, or actually shooting at all. 😁

Edited 10 hours ago by Rolf Kalbermatter