Allowing items (Vis) deletion in autopopulate project view ... and also new folder creation ... deletion ...

[manu.NET]

When you use the autopopulate view in Labview project you have a direct view on the OS directories.

You are able to add new elements, rename elements  ... but not to delete them !

It should be nice to add the ability to delete an items from the autopopulating view, using the "Context sensitive menu".

I also noticed that it is impossible to add/remove new folders ... you have to open a file browser to manipulate folder ... 

[AristosQueue (NI)]

I cannot count how many times I have removed an item from my project tree in MS Visual Studio only to realize too late that my file on disk had also been deleted. It usually happens when I want to submit a changelist to my source code control which includes a changed project file but I have another new file on my local machine in another changelist that I'm not ready to submit. I remove the one I'm not submitting from the project, and if I don't do it the right way, MSVS helpfully deletes the file from disk as well. 

This tale of woe informs the LabVIEW experience. The project tree initially had a mechanism for deleting from the project tree and from disk in a single popup menu item. Unfortunately, that leads to the need to have "Remove from project" and "Delete" as two separate options. Even with really clear instructions, there were some unfortunate events in which LV did exactly what it was designed and documented to do and some users wiped out files on disk that they wanted. As a result, we (and here I speak as one of those directly involved in the decision) decided that the LabVIEW project should not delete files. You have to be very precise when deleting files, and if the UI leaves even a bit of ambiguity, the result is sad users.

[tst]

To add to AQ's post - I think auto-pop. folders are really not necessary (and they actually hurt usability) - The project should hold the stuff you need access to. Anything else can be accessed using the dependencies section, the files tab or even the OS file manager.

[manu.NET]

Hy,

I think the autopopulate mechanism is good and safe way to wiew and store files, comparing to the Labview way, enabling to save files everywhere on disk ...

How many times you get a project with missing files ... which have been saved on user desktop for example ...

When the project stays on the origin computer .... the project works fine ... when the project is moved to an other computer ... catastroph !!!

Using the autopopulate mechanism give you the ability to structure your source code, and to find the same structure on disk.

I think that "Virtual project architecture" is far more dangerous than autopolating.

Manu. (MsStudio fan)

[tst]

I don't have a "virtual project architecture". I have my files on disk in whatever hierarchy I want inside the project folder and I have the stuff I need to access in the LV project. What I don't need to access is not placed in the project at all. I don't tend to have cross-linking problems, but you can always easily check where files used in the project are saved by using the Files tab.

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.