Darren's Weekly Nugget 04/06/2009

[Darren]

One of my favorite features in the LabVIEW 8.5 release was Auto Populating Folders in the Project Window.  I've seen a lot of differing opinions on this feature.  For example, some developers eschew auto populating folders because their behavior may not be entirely straightforward when the project contains libraries or classes (since those items are containers in the project, but not containers on disk).  Nevertheless, I'm a big fan of letting the Project Window do all the work in reflecting my project organization on disk so I don't have to.  Also, I have been happy with their use in conjunction with the Source Code Control functionality in the Project Window.

If you've found yourself struggling to keep your project's file structure in sync with your Project Window organization, I recommend you give auto populating folders a shot in your next project.

[tst]

And here's the flip side of the coin - you don't HAVE to keep the project in sync with the HD. I prefer having only the important files (VIs, CTLs, classes, documents, etc.) in the project. Those are the ones to which I want easy access. The rest of them can easily be reached through the files tab or the dependencies section. This is important - the files tab is essentially very similar to the auto-pop. option since it shows the hierarchy on disk.

Another downside to the auto-pop. folders is that you can't have the same file twice in the project hierarchy. If you want to have a specific VI at a higher level, you have to create a hyperlink to it.

[Jim_Kring]

Hi Darren,

One of the reasons that I don't ever use auto-polulating project folders is that .svn folders (containing source code control meta data) showin up inside the auto-polulating project folders.

Any plans to not show system/hidden/.svn/CVS folders inside auto-populating folders?

Any plans to allow users to specify exclusion patterns for auto-populating folders?

Thanks,

-Jim

PS - I also asked a similar question in the LabVIEW beta forum. 

Message Edited by Jim Kring on 04-06-2009 08:04 PM

[JK1]

Hai Darren,

As Jim pointed out the .svn or any other source code files get added to the folders while auto-populating and creates problems while creating installers.  It would be a welcoming option if the hidden files are excluded.

But i still like auto-populating option, it makes life easy, developer need not spent time in adding the folders classifying the required content

Cheers to Auto-populating folders

Thanks.

[pauldavey]

Auto-populating project folders are one of my favourite features too. They save me a lot of time and hassle when I already go to the trouble of keeping my files organised on the hard disk.

[Ben]

After going thru a conversion to LVOOP (mentally) I never user the auto-populating option.

In LVOOP it is more convient to organize my class logically in the project but by class on the disk.

Example:

Class A

Has public private and protected methods. Since non-members of the class only have acces to the public versions I keep the public methods in a Public virtual folder. If at a latter data I want to expose a method that was previously private, I can move it between virtual folders but the file stays at the same location on disk.

As mentioned earlier the "folder View" does what the auto-populating does so the two are redundant.

Just my 2 cents,

Ben 

[Darren]

tst:  I haven't ever thought about not including all the project files in the project...this is an option that some people should consider, I suppose.  For me personally, the project organization and the file organization are intimately linked...I can't imagine looking at a view of my project and knowing that there are files related to my project that aren't shown.  I guess this ultimately comes down to personal preference.

Jim:  It looks like your .svn issue from the beta forum is resolved (let me know if it's not).

Ben: For a project that is heavily geared toward classes and/or libraries, I agree that auto-populating folders may not be the best option (I briefly alluded to this in the original nugget text).  For these types of projects, my personal preference is to create a flat directory structure that contains one folder for each class/library in my project.  Each folder contains all member VIs of each class/library, along with the actual .lvclass/lvlib file itself.  I don't try to arrange the classes/libraries hierarchically on disk, as that would become a nightmare if I decided to change inheritance or parent properties of the classes/libraries during development.  With this arrangement, the directory structure on disk effectively mirrors the arrangement of the classes/libraries in my project.  I should also point out here that I've never developed an application with nested libraries, but I'm thinking I would stick to this directory structure in that situation, too.

[tst]

---

Darren wrote:

I can't imagine looking at a view of my project and knowing that there are files related to my project that aren't shown.

---

You could use the files tab for that. I just wonder what the difference is in your case between the files and project tabs. I'm assuming they either look exactly the same or that they're very similar.

The advantage in not putting everything into the project is in having easy access to the stuff you do need. I suppose this also has to do with how you interact with the project. Most of the time, I don't use the project window and just navigate through the open VIs by hierarchy. If you do open all your VIs from it, its tree structure probably helps, but I still feel you could probably get the same thing from the files tab.

And just to make it clear - I do have a hierarchy on disk and that hierarchy might even be represented in the project, but I'm not tied to it.

[crelf]

---

tst wrote:

And here's the flip side of the coin - you don't HAVE to keep the project in sync with the HD.

---

Totally - one of the most beautiful things about the LabVIEW project is that you don't have everything in there, otherwise it's just a glorifed file explorer (well, not really, but you know what I mean 🙂 ).  I use auto populating folders sparlingly, but I still use them - especially when there are dynamic VIs in my project (like a plug-in architecture) that automatically scan a physical folder that contains all of the plug-in VIs.  That gives me the exposure to new plug-ins (or removes plug-ins) when someone else working on the project adds/removes plug-ins.  I think the way of the world is to move toward more abstraction of the physical drive structure, and I see the LabVIEW project as an important step in that evolution.