Leaderboard

You know you can customise this to whatever suits you right? Edit CLSUIP_LocalizedStrings.vi in LabVIEWresourceFrameworkProvidersLVClassLibraryNewAccessors and change the Write and Read to whatever suits you. Don't forget to right-click-->make the value default on each of the string controls after you have changed it, and then save. Only pain point here is that it has to be done for each new LV installation

An LVLIB loads all its contained libraries and classes, but not its VIs. So it is OK to have lots of VIs in a LVLIB, even if not all will be used. It is only LVCLASS that loads all contained VIs. Note that if you have a class in a LVLIB, loading the LVLIB will load the class and thus all the class’s VIs. I generally do not put classes in libraries for thus reason. NI really should work at changing this. I can see why it might be necessary to load all dynamic-dispatch VIs, but not static ones.

The easiest solution would be to rename the private method to "PrivateReadDevice.vi", as the private interface can still be changed anytime without side effects on implementations (like linking issues). However your example should be two seperate classes in my opinion: One for serialized access (i.e. the implementation of a driver) and a second class for access in terms of a messaging system to an async. state-machine/process which implements the driver.

I find I have to watch out for optional VIs that extend a class’s functionality by using another class. It feels natural to include the optional VIs in the class; but, a class aways loads all it’s contained VIs. So this means that the other class and its dependancies always load when the first does, even if the optional VI isn’t used. If the unneeded-but-loaded classes also have optional VIs that use still other classes, then those classes load. It only takes a few “linker” optional VIs to cause huge numbers of unused classes and VIs to load. The key is to keep these VIs outside the class they are naturally a part of (I organize them in LVLIBs, often with the same name as the parent class). I once created a new project and added my top-level “Message” class, and this loaded twenty to thirty unneeded classes, all traced to two half-forgotten “linker” VIs. From a name-spacing standpoint this is rather undesirable, but until LabVIEW fixes the issue of a class always loading all it’s VIs it’s the only solution. — James

I recommend you check out the appendices in the paper linked in this thread: http://lavag.org/topic/14213-strategy-pattern-example/?hl=%2Bstrategy+%2Bpattern. One way to see the interdependencies is to create an empty project and add, say, a class to it, and see what comes along with it. Look at the tag-alongs and think about whether the linking is logically necessary or not. Paul

Mike, From what you say I would venture that the problem is that there are very many source code interdependencies, which will result in lengthier load times. If that is true, packed project libraries (which I generally don't recommend anyway) will not help. The appropriate solution is to use interfaces to minimize source code interdependencies. (I explain how to create an interface--or something very much like one--in several of my papers linked in LAVA threads. Basically you will need to add a layer above your existing abstract classes, and this new layer will have abstract methods as well. There are other steps to take to minimize interdependencies, but this is the main one.) I do not buy the argument that greater hierarchy depth alone dramatically increases load time. For instance, I have a class hierarchy 6 layers deep in my current project, which is not at all atypical in this part of my applications, and load times are quite normal. Paul