Leaderboard

This package will be available for download through VIPM in a few days and covers some bug fixes, performance updates, and new VIs. [FIX] 3386531 - Get Array Element Default Data does not support Timestamp [FIX] 3252254 - "Set Variant Name.vi" Kills Attributes [FIX] 3386530 - Create new Waveform and Refnum TD subtype VIs [FIX] 3386538 - Update Variant Constant to LabVIEW 2009 appearance [FIX] 3411109 - Recursive VIs should use native recursion (lvdata) [FIX] 3411324 - New VI: "Get Default Data from Variant" Waveform and Refnum Subtype Enums There are now new VIs and Enum Controls for determining the sub-type of Waveforms and Refnums datatypes. These VIs were designed by Jim Kring and solve the issue of parsing such datatypes as e.g. Timestamp (Waveform subtype) and VISA (Refnum Datatype). This will allow OpenG support such (sub) datatypes in e.g. Format To String.vi in the near future. Get Default Data from Variant This VI forms a thin wrapper around the Get Default Data from TD.vi complementing the Variant API nicely. You can New Variant Constant Image The Variant Constant image has been updated to be inline with the change made in a previous LabVIEW version both in the palette and on the block diagram.] There is no functional difference between the two constants. Here is a Test: Kind regards Jonathon Green OpenG Manager

I went through something similar about a month ago. Most of my classes are not in Libraries now, which is not really what I would prefer, but it is necessary if I want to only load necessary software (every so often I open a new project, open a fresh VI, and drop a single object into it and see how much loads up under “Dependancies”). It’s more than just Libraries; any VI in a class that refers to another class acts as a “linker”, causing that other class to fully load in memory. It just takes a few linkers to get a sort of “domino effect” as class after class loads up.

I wonder if placing those VIs in a disable structure or opposing case of a constant-wired case structure would trick the deployment into including them as well? It would feel a little less kludgy to me and you'd probably see an improvement in start-up time.

We went through pretty much the same process of discovery. Short answer: Yes, we put classes that work together to perform some specific tasks (e.g., configuration) in a library (.lvlib). We also put classes (or other files) in a library when a group of these form part of a template but in each instance we need a unique namespace. (The library provides a namespace and we don't have to rename all the individual contents. We can also copy the entire library on disk at once.) Finally, sometimes we have a group of child classes that obviously go together (for examples, we have Commands.lvlib and States.lvlib that contain children of CommandThisComponent.lvclass and State.lvclass, respectively.) In all cases we need all elements of the library in the project anyway, and it is actually quite handy to have everything grouped under a library in the project. (I think this is an especially important practice, by the way.) When these situations do not apply (i.e., we have a class that we may call all on its own) we usually do not put classes in libraries since we do not see an obvious benefit. (Putting disparate classes in a library adds unneeded items to the dependencies, as you say. We could make a library for an individual class, but especially since a class is already a library there doesn't seem to be anything to gain by doing that.) The other thing to keep in mind is that if you open a nested library it will open the parent library and any other libraries in the nest. Paul