LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

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

Status: New

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:

HowItsNow.png

 

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:

HowItShouldBe.png

 

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

Piotr Kruczkowski
Certified TestStand Architect
Certified LabVIEW Architect
9 Comments
Trusted Enthusiast

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

=====================
LabVIEW 2012


Trusted Enthusiast

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?

Member

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. 

Active Participant

Same goes for XControls!

Certified LabVIEW Developer

Trusted Enthusiast

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.

=====================
LabVIEW 2012


Active Participant

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 ...

 

 

_________________________
CLA
Active Participant

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.



Michael Aivaliotis
VI Shots LLC
Active Participant

@Michael_Aivaliotis:

The situation is a little different with classes than LLBs... This idea (as an option, like the op said Smiley Wink) 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.
--
Chris Virgona
Member
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.