Restore "Delete from Disk" in project Files view

[PaulLotz]

In LabVIEW 2009 one could right-click on a VI, for instance, in the project Files view and select a Delete from Files option.  (It didn't work perfectly--in particular, LabVIEW didn't always delete folders from disk, but it usually did work for individual VIs.)  NI removed this option in 2010, leaving the developer with the task of deleting files manually through the OS files view.  (This isn't the end of the world, of course, if a developer doesn't use integrated version control--and we don't currently but only because LabVIEW does not properly support integration with Subversion--but it is a significant inconvenience.)  This option ought to be present once more.

In particular, this function is absolutely required if LabVIEW makes a claim to provide integrated support of version control.  On that note, the current client (Pusk Ok SVN) LabVIEW supports for what is probably the most popular version control provider (Subversion) among its customers does not even claim to support file renaming or deletion (http://www.pushok.com/soft_svn.php), while a third party plug-in (http://jkisoft.com/tortoisesvn-tool/docs/) claims to support this behavior only for VIs and Controls (not, for example, LabVIEW class files).

[PaulLotz]

I meant to say "Delete from Disk" (not "Delete from Files") in the first sentence.

[tst]

I don't have 2010 installed, but if this feature is missing, I would call it a bug, not something that needs to be reimplemented.

[PaulLotz]

I don't disagree, but NI's perspective (as expressed through product support) is different:

"This behavior is not a bug, but expected. We did it for several reason, but mainly for ease of use.

It should not affect the execution of your project. You can always make a product suggestion:

http://digital.ni.com/applications/psc.nsf/default?OpenForm"

So it seems NI looks at this as a change in the feature set.

My perspective:

I don't think the removal of this feature overall improves the ease of use.

This by itself is not the most important feature to me, although I think it should exist in any case.

Where it becomes really important (necessary, actually) is to support a useful implementation of integrated version control, which I would really like to have.

[Integrated version control will be even more important to support a truly integrated library-based project view where the developer would not have to care about file paths at all, which is what I would like to see as the long-term vision for LabVIEW.]

[AristosQueue (NI)]

I was the one who deleted this option from the code base, though I had plenty of advisors in making the decison.

> I don't think the removal of this feature overall improves the ease of use.

No, it doesn't. What it does it is removes something that was -- judging from CARs reported -- hindering ease of use.

Delete From Disk does not necessarily unload from memory. Frequently, we can't unload from memory. I got several CARs that "I delete from disk, then I do Save All, then it is back on disk." There were other CARs that came in related to this -- "VI cannot recompile because diagram now missing", which came around because the VI was in memory, but we hadn't loaded the diagram because the window wasn't open and then a subVI of that VI changed, and now the VI cannot load its diagram, so it cannot recompile and so LV throws confusing dialogs.

Then there was the category of "Delete library from disk does not delete the library" CARs, by which people usually meant "When I delete the .lvlib file, all the VIs that are members of the .lvlib file don't get deleted, but they disappear from my project tree which makes me think they got deleted." There was something about autopopulating folders that made that case more interesting, but I don't recall the details.

There were CARs from people who felt that deleting the VI from disk should delete all the subVI calls to that VI from the VIs in their project and were confused when that didn't happen. Similarly, there were people who felt that deleting the library from disk should delete all the subVI calls to all members of that library in their project.

There were a few lost souls who chose "Delete From Disk" when they meant "Remove From Project". Yes, clearly user error, but it happened more often than I would have expected.  I had some pity for these people. There was another group that used Autopopulating Folders for whom I had less pity. With Autopopulating Folders, there is no "Remove From Project" option, because you said to include the whole directory, and some users would use "Delete From Disk" instead and then be upset when LV, guess what, deleted their file from disk. We probably could have created some sort of "Exclude From Project" option for those files, which I probably would have suggested a few years ago when we first introduced Autopopulating Folders, but seeing how often the plain "Delete From Disk" and "Remove From Project" were confused, I wasn't sure it would help.

I had been closing these CARs for a couple years as "Not A Bug." But at one point I had six of them stacked up in my CAR list, and I finally said, "Look, there's a problem with this option." I talked to a relatively large group of LV developers -- and here I resist the temptation to name names and thus spread the blame around -- and concluded that people wiping out files that they intended to keep was a significant deal, and telling users to delete the files after they remove them from the project (assuming they don't just move down to the Dependencies section) was a reasonable workaround. Thus we decided that removing the option was the right thing to do. And from there, I made the actual change.

The rightness/wrongness of this action has been debated back and forth, and now my CAR list is occassionally populated with "Delete From Disk option appears to be missing from LV 2010", so perhaps I've saved nothing in terms of CAR backlog, but at least none of these CARs are people crying about valuable VIs no longer existing.

[AristosQueue (NI)]

I was the one who deleted this option from the code base, though I had plenty of advisors in making the decison.

> I don't think the removal of this feature overall improves the ease of use.

No, it doesn't. What it does it is removes something that was -- judging from CARs reported -- hindering ease of use.

Delete From Disk does not necessarily unload from memory. Frequently, we can't unload from memory. I got several CARs that "I delete from disk, then I do Save All, then it is back on disk." There were other CARs that came in related to this -- "VI cannot recompile because diagram now missing", which came around because the VI was in memory, but we hadn't loaded the diagram because the window wasn't open and then a subVI of that VI changed, and now the VI cannot load its diagram, so it cannot recompile and so LV throws confusing dialogs.

Then there was the category of "Delete library from disk does not delete the library" CARs, by which people usually meant "When I delete the .lvlib file, all the VIs that are members of the .lvlib file don't get deleted, but they disappear from my project tree which makes me think they got deleted." There was something about autopopulating folders that made that case more interesting, but I don't recall the details.

There were CARs from people who felt that deleting the VI from disk should delete all the subVI calls to that VI from the VIs in their project and were confused when that didn't happen. Similarly, there were people who felt that deleting the library from disk should delete all the subVI calls to all members of that library in their project.

There were a few lost souls who chose "Delete From Disk" when they meant "Remove From Project". Yes, clearly user error, but it happened more often than I would have expected.  I had some pity for these people. There was another group that used Autopopulating Folders for whom I had less pity. With Autopopulating Folders, there is no "Remove From Project" option, because you said to include the whole directory, and some users would use "Delete From Disk" instead and then be upset when LV, guess what, deleted their file from disk. We probably could have created some sort of "Exclude From Project" option for those files, which I probably would have suggested a few years ago when we first introduced Autopopulating Folders, but seeing how often the plain "Delete From Disk" and "Remove From Project" were confused, I wasn't sure it would help.

I had been closing these CARs for a couple years as "Not A Bug." But at one point I had six of them stacked up in my CAR list, and I finally said, "Look, there's a problem with this option." I talked to a relatively large group of LV developers -- and here I resist the temptation to name names and thus spread the blame around -- and concluded that people wiping out files that they intended to keep was a significant deal, and telling users to delete the files after they remove them from the project (assuming they don't just move down to the Dependencies section) was a reasonable workaround. Thus we decided that removing the option was the right thing to do. And from there, I made the actual change.

The rightness/wrongness of this action has been debated back and forth, and now my CAR list is occassionally populated with "Delete From Disk option appears to be missing from LV 2010", so perhaps I've saved nothing in terms of CAR backlog, but at least none of these CARs are people crying about valuable VIs no longer existing.

[PaulLotz]

Thanks for the detailed explanation!  I had kind of guessed that there were some issues with its use that prompted its removal.

I actually did use this feature (carefully!) fairly frequently in LabVIEW 2009 since it saved a step and increased the likelihood that I would delete the correct file.  So I did notice right away that it was no longer present in LabVIEW 2010 (but I waited a while before bringing it up because I wanted to see if anyone else would comment on it).

Since we do version control outside LabVIEW (with TortoiseSVN) the absence of this feature is a minor nuisance at present here, not a huge deal.

On the other hand, I don't see how LabVIEW can support integrated version control without this functionality.  (Moreover, I think integrated version control is really a must now and will become even more important in the future.  Our team members would definitely prefer to use integrated version control but find the current offering with Subversion insufficient, so for now we have decided to stick with external version control using TortoiseSVN.)

[PaulLotz]

I should mention another usage example I have seen that concerns me.  One developer I know tends to remove a bunch of VIs from the project without deleting them immediately, then reconciles the project and the disk later.  This is, of course, an error-prone process (how does one avoid missing a file?).  This is certainly partly how the product is used (it would be better to delete the file from disk immediately after removing it from the project) but the Delete from Disk option helped the user avoid this situation in the past.  (Of course, if one didn't use this option in 2009 one could still end up there.)

[richjoh]

Correct me if I'm wrong but 2009 method of removing files was correct but the problem is 2009 erased the file and they never went to the "recycle bin" or "trash can". This is a problem, thus all the CARs swayed to address the issue and change was made to not delete files. Why can't the files be put in the recycle bin, because "delete file" context says exactly that thus misleading the Labviewer.

I've used LV integrated version control and it was too gauche with the chosen version control or maybe the other way around. Put the "delete file" in the recycle bin and when I commit, using TSVN, a new version, the list of changed files will show a file is missing. I could flag removal of the file from the commit version at that point. Or flag removal a different way by recovering the file from recycle bin, flag it in TSVN for removal then put the file back in the recycle bin.

Once NI creates there own version control, there will be no need for choice of version control and we could wind up with ....

[tst]

---

Correct me if I'm wrong but 2009 method of removing files was correct but the problem is 2009 erased the file and they never went to the "recycle bin" or "trash can". This is a problem, thus all the CARs swayed to address the issue and change was made to not delete file

---

That was only one of the problems mentioned in AQ's comment. Others had to do with the VIs still being in memory.

One option for this would be to not let LV delete a VI if it's still in memory or has open callers, but that would only help with VIs which are explicitly added to the project (either directly or because they're in an auto-pop. folder), because dependencies would simply disappear from the list when you unload them.

[JKSH]

---

tst wrote:

...that would only help with VIs which are explicitly added to the project,... because dependencies would simply disappear from the list when you unload them.

---

I would argue that one should always add code files to the LVPROJ. The only time files should be left out is if they're from a 3rd-party package, but one has no business deleting files from 3rd-party packages anyway.

From AristosQueue's case studies, the issues boil down to:

1. Bad Things(tm) happen if the VI is deleted from disk, while it's loaded in memory.
2. Users misunderstand how LVLIBs work (i.e. they store REFERENCES to VIs, not VIs themselves)
3. Users expect LabVIEW auto-magically clean their code for them when they delete a VI/library from disk
4. Users get mixed up between "Delete From Disk" vs. "Remove From Project"
5. Users forget/misunderstand how auto-populating folders work (i.e. the virtual folder is a direct mirror of the disk folder)

I believe we can have a delete-from-disk option, while idiot-proofing against the above 5 scenarios. Here are two methods:

Method 1: More confirmation dialogs

1. In the right-click menu, offer only one option: "Remove".
2. If the user has selected a file from a non-auto-populating folder, display the Remove Items dialog; otherwise go straight to #5.
3. Change the text of the Remove Items confirmation dialog: "The selected item(s) will be permanently deleted removed from the project or project library." (avoid the term "permanently deleted", when removing from Project only)
4. In the Remove Items confirmation dialog, add the checkbox option: "Delete file(s) from disk too"
5. If the user opts to delete-from-disk OR delete-from-autopop-folder, display another confirmation: "The selected item(s) will be moved to the Recycle Bin. Any VI or control that requires these files will no longer work.", with the option of "Do not show this dialog again".
6. If the user opts to delete-from-disk OR delete-from-autopop-folder, AND has selected a library, display another confirmation: "You have chosen to delete a LabVIEW library from disk. You may choose to keep the library's files, or delete them from disk too. If you delete them, any VI or control that requires these files will no longer work.", with the options "Keep files and add them to Project", "Keep files but don't add them to Project", and "Delete files from disk".
7. Modify the checkbox of the first Remove Items dialog: "Do not show this dialog again, and do not offer to delete from disk again". (I thought of allowing the option to ALWAYS delete from disk, but that's too dangerous)
8. Prevent deletion if the VI is still in memory. Ask to the user to unload it first.

Method 2: One big dialog

• Mostly like Method 1, but combined into a big dialog like the "Save As..." dialog for VIs
• No "Do not display this dialog again" option
• The "Remove from Project" option is grayed out if the selection contains the contents of an auto-populating folder (unless the folder itself is also selected)
• Copious amounts of text under each option, to describe what will happen