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 🙂
I like it. It goes hand in hand with the Bundled Project Library
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?
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.
Same goes for XControls!
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.
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 ...
This reminds me of the "good ol' days" of 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.
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:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.