Option for packing LV Class a single file .lvclass containing all the methods.

[PrimaryKey]

Hi,

It would be awesome if there was an option in project window to set if the method is contained within a .lvclass file or ouside of the .lvclass next to it in the folder.

Now it's like this:

It's hard to use a class like that in a plugin architecture with VIs on the outside. Lets put everything together inside like a LabVIEW LLB!

How it should be:

Don't get me started on Packed Project Libraries 😉 We just need LLB functionality, for the class to behave like a folder and we are happy 🙂

Piotr

[SteveChandler]

I like it. It goes hand in hand with the Bundled Project Library

[GregFreeman]

This is a great idea. Especially because I hate when I make a mistake in design and decide a VI needs to be in a different class, so I move it from its prior class to the new one from within LabVIEW. But, it still remains in its original location on disk. So I then have to do a save as... and move the file into the folder with its new class to keep things organized from an on-disk perspective. Major pain, often causing linking problems etc. 

The only potential issue I see is if you right click a method and remove the VI from a class. Where does it go? Before, it would still be on disk and you could add it back into the class if you wanted. Does it get deleted from the class to never be recovered again (with the exception of with SCC)? Would it force you to save it to a specific disk location? Or maybe give you the option to either delete or "save as" elsewhere outside the class? How would this be handled?

[fabions]

Other option would be to improve LLB functionality, since today the only workaround to keep all class files inside a single file is using the llb, but its just too "trashy" and "buggy" to work with llb manager. 

I think this Idea is great, and will make my life easier for organize the classes with other project files, and also to refactoring and reusage of classes. 

[JKSH]

Same goes for XControls!

[SteveChandler]

The other benefit, as Aristos Queue points out in the Bundled Project Library idea, is that one file will load much faster than a bunch of small ones. I am working on a project that uses object based messages extensively. Off the top of my head there are a couple hundred classes which translates into who knows how many files.

[stbe]

I don't like the idea to put multiple LV items (VIs, classes, ...) into a single file (and NI even show us that by moving away from LLBs).

Nowadays (almoust) every project should be dealt with SCC. If you now edit a single file with the whole (LLB, *something else*, ...), you also need to commit all the other files to SCC, even though you did not touch them ...

[MichaelAivaliotis]

This reminds me of the "good ol' days" of LLBs:

• LLB corruption was commomplace and in such cases you would lose access to all the files in the LLB
• SCC systems cannot get inside of LLBs and thus you don't have versioning (or all the other great features) on the contents.
• When loading or manipulating (save, save as, etc), you have to use NI's proprietary file browser dialog because the native OS does not understand LLBs.

No thanks. Let the OS handle files. I don't want NI adding another layer of interface which they have to maintain and worry about keeping bug free.

However, if you are requesting some new form of export or build specification, then perhaps that is a different request or suggestion.

[fabric]

@Michael_Aivaliotis:

The situation is a little different with classes than LLBs... This idea (as an option, like the op said ) offers some significant benefits for classes:

• A packed class offers a neat solution for dynamically loadable components: Just one file to distribute, and (presumably) no linkage issues like with PPLs...
• A modern architecture involving large numbers of accessors becomes much easier to swallow if we can limit the "load time hit" from all the tiny files
• Class members are intimately linked to the class itself, so forcing users to edit a packed class via the project is not so bad IMO... Moving class members on disk via the OS usually does bad things to your app.

[XA-LSTOM]

To make easier the distribution of .lvclass, it would be interesting to create packed lvclass (.lvclassp) like lvlibp for lvlib. A second idea is the possibility to call public lvclassp 's Methods in Teststand.

[JimB.]

+1 on .lvclassp.