Allow a subvi to be closed without saving at any time.

[RWR]

I often open a subvi while the calling vi's are open.  I make a few changes.  I try the changed code and decide I prefer original.  If I try to close the vi without saving it is not possible.  I must select "defer decision" to save.  Then when I later close the main vi, I am asked to decide whether to save the subvi or not.  By then I may have forgotten that I did not want the revisions saved or simply use the apply decision to all by mistake.  Allowing a close without saving at anytime would be most welcome.

[JackDunaway]

This is a great Idea, and a duplicate of 'Do Not Save' Option, but I would prefer if it were not marked as such for a few days. Sometimes it takes a duplicate Idea to stir the pot on a good Idea that needs revisiting.

Spoiler

Warning: That thread contains... rather verbose anecdotes on why I think it's a great Idea.

[K CRAFT]

I agree; however, I have found the following workaround with current version of LabVIEW. 

'Revert' the Sub-VI via the file menu before closing.

[AristosQueue (NI)]

"Do Not Save" option on that dialog was rejected when the dialog was designed. There are several reasons for this.

1) If a VI is currently running, it cannot be reverted, so there were at least some times when it was impossible to close and not save the changes.

2) There are already many buttons already on this dialog and various test users complained about too many options when another button was added. Recall that prior to LV 7.0, there were up to 7 buttons on the Save Changes dialog (depending upon conditions of LV at the time that dialog was invoked) and we were trying to fix that UI disaster.

3) As mentioned by K CRAFT, the option of File >> Revert does exist, so there is a way to get this functionality.

In short, we thought about it, evaluated it, and rejected it.

[djs2571]

We do need this "close without saving" button, it's not user friendly the way it is now. Fewer clicks to get the job done - always a good thing to do when possible.

[AristosQueue (NI)]

> Fewer clicks to get the job done - always a good thing to do when possible.

Unless an additional UI element makes other jobs less possible, which is what we found in this case. And there are times when extra caution is warranted, such as when dealing with throwing away unsaved changes. The old Save Changes dialog had many cases of people throwing away changes that they intended to preserve, and feedback suggested that happened just from confusion over too many buttons.