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.

[tst]

Defer is useful, because sometimes you DON'T know immediately. You might want to make changes on a bunch of VIs and test them without saving.

As for the SCC\recompile issue, you might be able to resolve this today by checking the option called Do Not Prompt Saving for Automatic Changes in Read-only VIs (or something similar) in the options menu. It's designed specifically for SCC, but it has a drawback in that it assumes that the VI is read-only and that you explicitly check out the VIs you want to edit.

What might be helpful was if the Save All dialog included a checkbox called "Don't Show Automatic Changes". Checking it would remove VIs which are only recompiled from the list and would allow you to see which VIs you actually changed, regardless of their read-only state. Of course, once it was checked, the auto-changed VIs would NOT be saved, since they're no longer on the list.

[AristosQueue (NI)]

"Don't Save" when the VI is still staying in memory is extrordinarily confusing to many people. People think their changes went away. But the changes stayed in memory, and they're mystified about why their VIs aren't working the way they expect them to. It gets really ugly. 

The interlocked files of LabVIEW, where file A keeps file B in memory, is essentially unique in the application world. That "Save Changes" dialog is really really hard to design because people expect it to be easy to use but it isn't an easy situation at all. The only real solution is to change the definition of what a VI actually is.

[JackDunaway]

tst...

If I'm ever "testing" a bunch of new source, I am always saving it to disk (local HD). If I don't like it, I delete the files and get a clean copy from the SCC server. It seems unsafe to me to leave a lot of unsaved changed in RAM...

Basically, you're saying this: your "sandbox" is RAM, and your "repository" is your hard drive. My sandbox is my hard drive, my repository is the SCC server (and my redundant backups are scattered over my coworker's check-outs on their computer).

AQ...

I'm dense. I have come to understand a lot of confusing things about LabVIEW, but even when I was just learning a few years ago I would have not found the situation you described as confusing. If I close the FP of an edited VI, it doesn't take a mental leap to realize the changes you made are going to stay in memory until other callers release it from memory.

If this person you are describing does not understand why the VI is keeping the unwanted changes in memory, just pop up a friendly notice after clicking "Don't Save" that says "The changes in DontWantChanges.vi will be erased once TopLevelCaller.vi stops running." (These "dummy notices" will default to "on" on a clean install, but the power user can optionally turn them off).

Regardless of whether anyone wants to actually implement this "Don't Save" idea, can I at least get some validation that I'm not the only one who wishes they didn't need to "Defer" when you really know right then that you don't want to save??

And am I the only one who shuts down his top level at the end of the day and gets a prompt wanting to save dozens of VI's, which triggers twitchy narcoleptic schizophrenic paranoid fits about losing all the work I've been working on all day (even though in the back of my mind I'm relunctantly, counterintuitively assuring myself that it's OK to not save everything)?

And is it really, really hard... assuming the verbiage is complete, descriptive, and most importantly concise... to understand that "Don't Save" will keep changes in memory until you allow the edited VI to be released?

AQ - I'm not disputing your knowledge... you know way more about the wide variety of customer experiences with LV as a product, and you know way, way more about the LV language, and you know way, way, way more about underlying source of the IDE. But at this point, I still can't see how your argument has more merit.

Message Edited by mechelecengr on 08-28-2009 12:16 AM

[tst]

> The only real solution is to change the definition of what a VI actually is

Hmm, sometimes it's hard to tell whether you're saying these things as "and that won't happen" or as "and just wait a couple of months till the next version comes out". 😉

> Basically, you're saying this: your "sandbox" is RAM, and your "repository" is your hard drive.

In this specific example, yes. I feel it's a perfectly legitimate use case, even if you do use SCC.

> can I at least get some validation that I'm not the only one who wishes they didn't need to "Defer" when you really know right then that you don't want to save??

That's exactly what the idea is about. Everyone who voted agrees with you on that.

As for the automatic recompiles, if NI decouples the machine code from the source code, this will stop being a problem. There are pros and cons to this which have been discussed elsewhere (possibly even on this board) and I believe NI has been working on the issue.

AQ, personally I doubt the wording matters much, because people don't read text. There was a thread in the BreakPoint when 8.x changed "don't save" to the much more accurate "defer updates". Did that change help? Not at all. Veteran users were going "OMG! What does that mean?" even though the behavior was identical to the previous one and its name was more accurate.

I agree that it's important to have proper wording, but this is a feature I wouldn't mind having and it seems to me that having a pop-up explaining the issue to new users might help.

After all this, though, I have to say that the issue isn't that annoying for me personally - I run into it every once in a while, but it's not exactly critical. I feel that a lot of the problem could be solved if the auto-change VIs would not appear in the list (like the checkbox idea I posted earlier) or would appear differently in the list.
This will allow you to review the VIs which actually changed and to decide if you want to save them or not. For the rest, it's rarely important whether you actually check them in or not, because even if the "wrong" version is saved, they will just be recompiled when opened.

Also, just to disarm the answer before you give it - the "do not prompt..." checkbox will not help in my case, because the VIs are not read-only and I don't check them out when I want to edit them.

[JackDunaway]

tst... We are a "smaller" software team, so we do not "check out" in the traditional sense that the person with the checked out module is the only one who can edit. We all have the entire project checked out, and can make changes and commit any VI we choose. Verbal communication takes care of 95% of confusion about who's working on what code, and SCC cleanly handles the 5% that may have caused a collision between two working copies. All this to say, the "Read Only" method is a good idea, but wouldn't work for us.

AQ... And let me try to chink away at the "confusion" argument once more. The current dialog is MORE confusing than my proposal. Currently, you get the words "Defer Decision." Defer until what happens? Defer until when? There is no immediate indication on how long the decision will be deferred. "Until the VI leaves memory", you must explain to the new user. Your quote above describes CURRENT behavior, not the behavior I am proposing! "People think their changes went away. But the changes stayed in memory, and they're mystified about why their VIs aren't working the way they expect them to. It gets really ugly." If you [X] a VI, hit "Defer Decision", and open the VI again, the changes are still there! Confusing! Because there was no indication as to how long the decision would be deferred.

OK, now take the dialog I'm suggesting. You click Don't Save, but the VI is still running. A dialog announces "The unsaved changes will be discarded when TopLevelVI.vi stops running and releases ThisVIYouDontWannaSave.vi from memory." See what has happened... you have given the developer the more powerful option of making decisions NOW, and you have explained exactly what action has to happen before the changes are waxed. If the user opens the VI again, sees his unwanted code is still there, and tries to [X] again to get rid of the durned changes, He'll hit "Don't Save" and the dialog will come up again: "The unsaved changes will be discarded when TopLevelVI.vi stops running and releases ThisVIYouDontWannaSave.vi from memory." Oh, this time he reads it. All's Good, Pro and Newbie Are Happy With "Don't Save" Option, We're Not Confused.

___Edit___ 

(and by the way, it has just occurred to me that it would even be helpful for the pro to see what VI's are reserving a VI for execution)

___End Edit___

Message Edited by mechelecengr on 08-28-2009 08:18 AM

[AristosQueue (NI)]

> And is it really, really hard... assuming the verbiage is complete, descriptive, and

> most importantly concise... to understand that "Don't Save" will keep changes in

> memory until you allow the edited VI to be released?

As far as I was able to tell, yes. The problem is -- again, as far as I could tell -- that "Don't Save" means "throw my changes away right now" in every app in the world. Currently, that includes LabVIEW. If we add a "Don't Save" option that doesn't throw the changes away right now, it creates confusion. So instead, you say, we could add an option that is something like "Keep changes for now but silently throw them away when this VI does finally leave memory". Let's call it "Toss When Able" for the moment. Great. But that doesn't remove the need for a button that says "I'm still making changes to my VIs, I'm not sure if I want to keep these changes or not at the moment." So we need a button for that... let's call it "Defer Decision. 

So now the dialog has "Save", "Defer Decision," "Toss When Able" and "Cancel." Now the problem is that we have two strange buttons instead of one. Once again, we hit up against the "this should be easy, why are you making me think" frustration level. It appears that people generally don't mind one strange button in this situation, which they can process as an exception to the rules, but give them two such buttons and now it is too confusing. People repeatedly hit the wrong one, even when they knew what they wanted to do.

So, in the end, we have only one confusing button, and it is the one that you can't accidentally throw away work you wanted to keep.

[mzaleski]

+1 to JackDunaway's clarification.  The Defer decision drives me nuts when I KNOW I want to discard the changes in a large project.

AQ, I love you man but spend a month in a combined PC/cRIO project with shared VI's.  LabVIEW insists on recompiling the VIs to whatever target I'm currently looking at.  After a couple of hours of programming, you have NO idea which VIs should really be saved.  I think there is already another Idea entry out there for us PC/RT developers and I kudo'd it.

[AristosQueue (NI)]

> AQ, I love you man but spend a month in a combined PC/cRIO project with shared VI's.  LabVIEW

> insists on recompiling the VIs to whatever target I'm currently looking at.  After a couple of hours

> of programming, you have NO idea which VIs should really be saved.  I think there is already

> another Idea entry out there for us PC/RT developers and I kudo'd it.

Believe it or not, I do understand...  I didn't say it wasn't frustrating and annoying as it stands. I've just been explaining why it probably could be worse and why the dialog itself may not get better.

HAVING SAID THAT, I WANT TO DROP A HAPPIER NOTE INTO THIS CONVERSATION...

Good news: there's another feature already in the works that will remove the recompile issue from cross-platform development. In fact, this same feature should remove most if not all of the "unreal" docmods that appear in LabVIEW today, leaving you with docmods only for real changes.  No promises for 2010, but it is in active development. Keep your fingers crossed. 

[tst]

Are you refering to DFIR?

[AristosQueue (NI)]

> Are you refering to DFIR?

Nope.