LabVIEW
Renaming auto populating folders
Solved!
@Ben wrote:
wiebe@CARYA wrote:
...I never noticed any slow down, but then again I might be used to it.
Trying to help a fellow wire-worker...
When the project tops 100- VIs, you will notice.
I actually go a step beyond the virtual folders and use virtual folders inside of Libraries (see here for a blog I wrote about libraries). I have found that a developer only has to clone a library once to fall in love with Libraries (and the virtual folders used to define the scope).
Try it, you will like it!
Ben
I'm at around 2800 VIs, and only months ago didn't even have an SSD... Loading takes a while (a minute or so) but I think that's caused by class hierarchy complexity. I never linked that to auto populating, but I guess it's possible. The SSD didn't speed that up though.
Using libraries are a problem, because auto-populating doesn't play nice with them. I see that more as a problem with libraries that should be fixed, then a problem with auto-population 
.
Almost everything I have is already in a class, but I would like to group classes in libraries... But preferably in auto populating folders.
Search LabVIEW like a graph! 
@Ben wrote:
wiebe@CARYA wrote:
...Almost everything I have is already in a class, but I would like to group classes in libraries... But preferably in auto populating folders.
So we find that a method needs changed from Private to Public.
Does that mean you mark the scope of each method individually or do you move the methods to another folder?
If the former, does that end up being more tedious to find and set?
If the later, when you export the code to deploy on a machine, don't you have to watch for VIs of the same name in different folders?
Like I said, I am just trying to help.
Ben
I'm OK with virtual folders in my class, for instance to mark VIs as private or protected.
@Ben wrote:
wiebe@CARYA wrote:
...I never noticed any slow down, but then again I might be used to it.
Trying to help a fellow wire-worker...
When the project tops 100- VIs, you will notice.
I actually go a step beyond the virtual folders and use virtual folders inside of Libraries (see here for a blog I wrote about libraries). I have found that a developer only has to clone a library once to fall in love with Libraries (and the virtual folders used to define the scope).
Try it, you will like it!
Ben
I would be totally lost without virtual folders within libraries.
I like virtual folders because if you move stuff from virtual folder to virtual folder, the only thing that changes for SVN is the project file. Moving from one autopop folder to another amounts to a physical move, so you have to resolve it in both LabVIEW and SVN.
Renaming a virtual folder is a simple task, too, for the same reasons. I usually have a controls folder and a VI folder (maybe a global folder if I have globals) for each library. I use virtual folders to organize. If you complain about having a disorganized mess in your folders, well... you shouldn't be poking around and opening LabVIEW files outside the project anyways.
@billko wrote:
If you complain about having a disorganized mess in your folders, well... you shouldn't be poking around and opening LabVIEW files outside the project anyways.
Not sure how that applies, no complains about that, and I don't know why I should poke around and open LabVIEW files outside projects?
The main problem with using (only) virtual folders is that there is double administration. I hate administration, but double administrations is 10 times worse. In short, when my code is in a virtual folder, and I add a file, it needs to be saved. The virtual folder has no reference (per se, it seems like something you want to do though) to the physical folder, so when saving the new VI, I basically have to know (or guess) where to save it. Even if I get it wrong, I won't notice. Not until I need to copy the code, and find out a VI in the class\library\folder is stored somewhere else. Or delete an obsolete folder, only to find out there where other VIs stored in that folder.
Now I'm sure this isn't a problem big enough when your used to only virtual folders, but it is when you're used to auto populating folders.
wiebe@CARYA wrote:
@billko wrote:
If you complain about having a disorganized mess in your folders, well... you shouldn't be poking around and opening LabVIEW files outside the project anyways.
Not sure how that applies, no complains about that, and I don't know why I should poke around and open LabVIEW files outside projects?
The main problem with using (only) virtual folders is that there is double administration. I hate administration, but double administrations is 10 times worse. In short, when my code is in a virtual folder, and I add a file, it needs to be saved. The virtual folder has no reference (per se, it seems like something you want to do though) to the physical folder, so when saving the new VI, I basically have to know (or guess) where to save it. Even if I get it wrong, I won't notice. Not until I need to copy the code, and find out a VI in the class\library\folder is stored somewhere else. Or delete an obsolete folder, only to find out there where other VIs stored in that folder.
Now I'm sure this isn't a problem big enough when your used to only virtual folders, but it is when you're used to auto populating folders.
It's strictly my preference, but it saves me lots of time when committing stuff to SVN. Because a move from virtual folder to virtual folder is... well... virtual, it saves from having to do tricks in SVN to re-align with SVN. True, you can just close your eyes and commit, but if you do that, SVN thinks you deleted one file and added another. The proper way to do that is after moving the file in LabVIEW, you do a "repair move" in SVN so it knows it's the same file and your SVN history moves along with the file. It gets even more complicated when you move a real (autopop) folder.
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
If you complain about having a disorganized mess in your folders, well... you shouldn't be poking around and opening LabVIEW files outside the project anyways.
Not sure how that applies, no complains about that, and I don't know why I should poke around and open LabVIEW files outside projects?
The main problem with using (only) virtual folders is that there is double administration. I hate administration, but double administrations is 10 times worse. In short, when my code is in a virtual folder, and I add a file, it needs to be saved. The virtual folder has no reference (per se, it seems like something you want to do though) to the physical folder, so when saving the new VI, I basically have to know (or guess) where to save it. Even if I get it wrong, I won't notice. Not until I need to copy the code, and find out a VI in the class\library\folder is stored somewhere else. Or delete an obsolete folder, only to find out there where other VIs stored in that folder.
Now I'm sure this isn't a problem big enough when your used to only virtual folders, but it is when you're used to auto populating folders.
It's strictly my preference, but it saves me lots of time when committing stuff to SVN. Because a move from virtual folder to virtual folder is... well... virtual, it saves from having to do tricks in SVN to re-align with SVN. True, you can just close your eyes and commit, but if you do that, SVN thinks you deleted one file and added another. The proper way to do that is after moving the file in LabVIEW, you do a "repair move" in SVN so it knows it's the same file and your SVN history moves along with the file. It gets even more complicated when you move a real (autopop) folder.
Shouldn't the folders be pretty much fixed, guided by a solid design 
?
OK, just kidding. Guess there are ups and downs to both ways, and whether the ups or downs win, seems to depend mostly on what one's used to.
I'm not closing my eyes for virtual folders only. It's just that my current (~6? year and going) project uses auto populating folders. Doesn't make much sense to switch now. Others in the company are looking into virtual folders, so at some point we could do a fair comparison.
Another discussion is how we can eliminate the cons for both methods, getting the best of both. I'd really like it if auto populating folders where adapted inside libraries where possible. Since it can't be guaranteed (library content could be somewhere else), it's not allowed at all, which seems a bit harsh to me. Some hybrid form would be nice. Right now, that is stopping me from using libraries at all.
I will stop after I dangle one last (for now anyway) carrot.
Rather than view the libraries and virtual folders as additional work, they can be seen as another method of communicating more information to readers of the code (and that includes me since I work many projects and remembering what I did on that project last year is not always guaranteed smiley-wink).
Let's go with an analogy...
I could hold up a soda can showing you the bottom and it would look like a circle. Hold the can upright and it would look like a rectangle. But offering a perspective view it would be seen as a cylinder. More than one view allows for the THING to be more easily understood.
Now with Libraries I keep each library in a unique folder named the same way the library is named. If I want to use that library in another project, I can copy the folder (which contains the lvlib) to a folder in the file hierarchy of the new project and I can start using it. I do not have to include the library in the new project. I just let it live in dependencies. Nothing earth shaking about that approach.
But then organizing the files in that library into virtual folders within the library lets me offer some order within the library. This is the second view I mentioned in the soda can analogy.
But libraries offer yet another way to convey information about the code. Here are some images to illustrate.
Before libraries my hierarchy screen would gradually become less useful as the project grew. Since the hierarchy screen will display VIs based on their name and location on disk. Here is an example.
But click the "group by libraries" button and we get this.
In the following image I can easily spot which test steps (those VIs at the top are test fro Test Stand) utilize what hardware.
I will stop there.
Just tying to help out,
Ben
