Project Explorer: organizing Items versus Files

[cebailey]

What is the difference between a Folder(Snapshot) and Virtual Folder?

From what I can tell so far they look and act the same in the Items view.

Could it be that they really are the same thing once you create them, but during that creation you use an existing folder on disk as the model for a Folder(Snapshot) and you make up anything you want as a Virtual Folder?

[TCPlomp]

---

cebailey wrote:

Could it be that they really are the same thing once you create them, but during that creation you use an existing folder on disk as the model for a Folder(Snapshot) and you make up anything you want as a Virtual Folder?

---

Bingo.

Snapshot is just a little macro that scans a folder (in older LV 8.2 even hidden files/folders) and build a Virtual Folder.

What most people don't know is that you can store your own persistant tags into LVProject files!

There are specific methods to read and write those (and I like the idea).

Ton

[cebailey]

Tags? What are tags and why do we want to do something with them?

Now I have organized a project into various virtual folders in the Items view and the corresponding files are all just sitting in the same place together in the Files view or the Microsoft Windows Explorer view.

So, items are organized 4 different ways, right? The hierarchy of caller-callee that is built into my application and illustrated in View Hierarchy, theProject Explorer Items view, the PE Files view, and what we see with Microsoft Windows Explorer. The caller-callee hierarchy is fully defined by our program logic and we don't manipulate the hierarchy as such. The Windows Explorer organization shouldn't be messed with because doing so will break links. But we can do what we want with the Items and Files ways.

The Items view has some advantages. If we add a vi to it, and the vi calls other vis, these other vis get added to the Dependencies section. We can move these from Dependencies to whatever folder we want (though we can't move them back to Dependencies, and apparently things in Dependencies aren't part of the project until we move them: "Check the dependencies section to make sure you've added everything you need to your LabVIEW Project - if you have not done so, remaining files rae listed in this section. This is an important practice for ensuring you're using the copy of a subvi you intended."). In the Items view we can make folder hierarchies. Also nonfile items are visible in Items. And we can right click on the .lvproj and Find Items with No Callers. It seems clear we would want to organize things in the Items section.

So once Items has been organized, what is the motivation to organize in the Files view? It might be nice to duplicate the organization we did in Items, so we can see it in Windows Explorer when we aren't running LV, but it would be a lot of work, right? There isn't a way to force the Files view to adopt the organization of the Items view, is there? And if we did this, vis we included in this project but also use in other projects would get moved and break the links for those other projects. If we use autopopulating folders, the work is reduced, but it sounds like they're not trustworthy yet.

How do you add folders to the Files view? It doesn't seem to work like the Items view does, and adding folders using Windows Explorer doesn't seem to do it. What'd I miss?

A vi does not know that it is part of a project, does it?

Thanks everybody for all the help. It's giving me a far better idea what PE is good for.

[cebailey]

Wait, things are getting worse. What IS the Files view? It doesn't necessarily match Items or the Windows Explorer version of where things are, and it doesn't change anything, does it? Is it an imaginary island unto itself, that is not connected to anything at all???

What do we really not want to do with Project Explorer, mistakes that take a lot of work to fix?

Autopopulating folder use sounds like one.

Moving project files on disk with something other than Project Explorer, so it doesn't know, sounds like one (maybe causing crosslinking).

[cebailey]

Moving files between folders in the Files view in PE has the same effect as seen by Windows Explorer and the OS, and doesn't break links in this project. That's not an imaginary island. My mistake.

If I use Utilities\ConvertScale.vi in this project and also in another project, and I use PE in this project to move ConvertScale.vi from Utilities to Utilities\Numeric, do I break the link the other project had to it?

[TCPlomp]

There are two items added after the initial project release:

• Auto populating folders
• Files view

This was not done based on requirements by the developers, but based on feedback from users.

I hardly ever use the files view. Only to check if everything is in the right folder.

Ton

[Ben]

Adding a couple of items not mentioned previously in this thread (I think).

The "Source Distribution" available in the PE will pick-up all of the sub-VI's used by a VI and move it to a new location AND update all of the links to point at the new location. This will leave all of the "un-used" VI's behind. If you are using dynamic VI's use a "Tree.VI" as the top level VI.

THe PE really shows its power when working with Libraries for LVOOP, XControls, DSC, etc.

I avoid putting all of my VI's in a single folder. That would make grabbing copies of sub-VI for ueas in another app very tedious.

I don't use to folder view except to check file location (like Ton).

In LVOOP there are limitaions on where the methods can be located relative to the file describing the Class. So I don't have any flexibilty in where to save these files. In a recent app I delievered they (all of teh classes) ended up in a single "Plug-ins" folder with a unique folder for the methods of each class. Using item view I arranged them such that they emulated their inheritance. This was nice because if I changed the inheritance, I just changed the item view and all of the files stayed in the same place.

Ben

[cebailey]

I think you can't just create folders in the Files view, like you can in Items.

But if you are in a vi that is part of a project, and click File > New vi, and save the new one in a folder, that vi and folder become part of the Files view.

And from Items if you add a file of any type to the project, any folders that are part of its path now appear in the Files view.

[jsiegel]

The files view is helpful if you want to move files to a new physical location on disk.  If you move a VI in Windows Explorer (by dragging it to a new directory), the links to subVIs and from calling VIs would no longer be correct; but if you do it in the files view, all the links are updated.

[cebailey]

Will, starting from your 1. 2. 3. and learning from the other posts seems to have gotten far enough that it now feels like a solution. It would still be nice to learn more if people are inclined to post, though.

Especially, tags and autopopulating bugs and use strategies remain interesting.

Thanks everybody!