Do Not Save Option

[elset191]

I want a Do Not Save option in addition to Defer Decision and Save.  When I was checking to see if this has already been Idea'd I found this thread.  Dennis mentions the Revert option, which I didn't know of.  I will probably start using this.  But, I still think Do Not Save should be included in the dialog.

[JackDunaway]

I'll agree to this. Here's why:

I often keep my top level open all day long, and throughout the day, I may close out VI's that I don't want to save, and instead must choose "Defer Decision". I don't need to defer my decision - I know my decision - I don't want to save. Later, I close the top level at the end of the day, and it reports "You have 423 unsaved VI's, whaddaya wanna do?" (And yes, just the other day I had a number in the 400's. [Well, it was when I upgraded to LV9, but typically I'll only have several dozen]).

The current "workaround" is to File->Revert the VI, then close it. We need an option that says "Close and Lose Unsaved Changes", or the like...

Message Edited by mechelecengr on 08-25-2009 11:26 AM

[elset191]

I do the same thing with the top level VI.  I just learned about the revert thing today, so what I did was just close everything, so I didn't forget which VI it was that I didn't want to save, and clicked don't save when that popped one popped up.  Real annoying.

[thols]

Reverting lots of VIs is not too fun, and won't work for the most common case: recompiled VI. I would like to have the option to filter out those kind of "I don't care" reasons to save the VI. Hmm, perhaps someone has already suggested that...

[crossrulz]

And has anyone noticed that with the RCF turned on, it is always "Defer Decision" and not "Don't Save"?

[RavensFan]

What is "RCF"?

[Chris_in_Colorado]

Revert is ok, but it comes at the wrong time.

Add a revert option or do not save.

Give the people the power!

[AristosQueue (NI)]

The existing Save Changes dialog was introduced in LV 8.0. During that refactoring, we considered adding a Revert button to the dialog. The options would have been "Save", "Revert Changes" and "Keep Unsaved In Memory". We tested this dialog. The feature was dropped because

1) If everyone will think back, LV 7.0 had a gigantic 7 button Save Changes dialog. That was refactored into the existing Save Changes dialog. The number one complaint of the old dialog was "too many options." When we simplified down to the three options, people still complained about too many options. The people who found Revert useful were very very rare.

2) Revert cannot always be an option. For example, if the VI is currently running, you can close it, but it cannot revert while it is running. It was hard to explain, within the dialog, why the Revert was sometimes grayed out. 

In short, we spent six months on that dialog in LV 8.0, and the feature being requested here was explicitly rejected. This idea is unlikely to go anywhere. 

[tst]

The option requested in the idea was NOT "revert". It was "don't save". This means that when the time comes to remove the hierarchy from memory LabVIEW will simply ignore this VI.

[JackDunaway]

tst nailed it. I understand the terms and implications of "Revert" and "Defer", but it took a while to get used to them. I'm suggesting to just use really simple, document standards: if you hit [x] with unsaved changes, give three options: Save, Discard Changes, and Cancel.

Let's look at AQ's #2 example: If I have a VI open with unsaved changes, and it is now running and I want to close that VI's FP, and I specifically want to discard those unsaved changes, I should have the option to "Don't Save", or "Discard Changes." As soon as it's able to leave memory (e.g., stops running) it just leaves memory without another dialog saying "Well, you deferred your decision until now, so whaddaya wanna do?" By that time, I may have hit several other BD's, and not even remember whether I want to save that one or not. Worse, I could have a host of 400 other VI's that are wanting my explicit attention in the Save Dialog.

Revisit that VI that I clicked "Don't Save" on, and assume it's still in memory (still executing or reserved for execution) with the unsaved changes that I decided I wanted to toss. If I were to open that FP again, it would have an * by the title indicating unsaved changes, meaning if I hit [x] again, it would ask me again if I wanted to Save, Don't Save or Cancel. This seems to be the ONLY case where it might be "confusing" that "Revert" did not work the first time the FP was shut down, but it shouldn't be that confusing. I mean, the run arrow is either going to show that it's running or reserved for execution, and the user can't edit the BD. Nearly all confusion would be eliminated anyway, because the only source of confusion is if you open the FP again after choosing "Don't Save" (whereas, with the previous method of greying out the "Revert" option, the confusion would have always been present in the dialog).

[JackDunaway]

Let me add more thoughts.

Here's a bold statement: "Defer" generates more confusion for the power user than it does the new LV user. A new user has to keep mental track of maybe a top-level and a few subVI's. A power user is going to hit dozens of VI's in a workday, and those changes could affect hundreds of VI's (think editing one of those backbone typedefs).

At the end of a typical day, I have somewhere between 10-100 VI's that want to be saved as I shut down the top level HMI or RT. I get temporary paranoid schizophrenia, every day. Guaranteed. "Am I about to wax an entire day's work?! This looks bad, not saving this many VI's!!"

Here's the main reason I NEVER hit "Save All" for all those recompiled VI's when editing those backbone typedefs: SOURCE CODE CONTROL. When I go to check in my changes at the end of the day, I typically do a root-level commit. If I were to "Save All", that means I would have to trudge through all the VI's that I actually changed, and separate them from the VI's that were "changed" due to a recompile. I never want to check in a VI just because it recompiled: we do a mass compile as needed specifically to iron out those changes. There's less "noise" on the SCC system, where check-in's always contain the pertinent VI's to the edits.

So, in short: "Defer" is never necessary if you know immediately what you want your decision to be.