The future of Project Libraries: We need your feedback!

[D*]

• Loading the entire library when a single vi is used prevents me from using libraries more.  For example, I have ~a dozen utility error/boolean VIs that I've created.  95% of the time I use ErrorOrTrue, 3% of the time I use ErrorOrFalse, and 2% of the time I use one of the others.  I would like to put them in a library, but I can't justify dragging around all those unused VIs.  One or two libraries like that are manageable, but if you repeat that n times pretty soon you have a project that takes 6 minutes to load and 4 minutes to close.

Totally agree.  I like taking a 3rd party instrument driver, which may have 100 dll calls that were individually wrapped with .vi's and putting them in a .lvlib, and know that everything is name spaced.  I only use a few of these calls, however, and now I'm running into your problem.  My project is taking minutes to load!   Is there a workaround?  (Is there a LabVIEW.ini key perhaps to turn "off" this feature?)

[tst]

as far as I know this is only true of classes. Other libraries should not load their files when they load. They might have other effects on project load times, though.

[AristosQueue (NI)]

Tst is correct. Classes and XControls load all their member VIs. Plain libraries do not.

[D*]

Tst is correct. Classes and XControls load all their member VIs. Plain libraries do not.

If a class loads, does it load all of it's subvis (even those outside the class's .lvlib?). 

I notice if I clear my object cache, and reload my project, I see a lot of .vi's compile when I open the project, including ones outside of .lvlib's.

-D

[tst]

To save AQ some time, when classes load they load all their VIs. When each VI loads, it loads its subVIs even if they are not in the class, just like any other VI does when it loads.