"Save All" needs a soft barrier to prevent accidental use

[altenbach]

As briefly outlined here already, The "File...Save All" menu entry is currently very dangerous and can lead to unintentional damages that are difficult to repair.

The "Save All" entry is very close to the "Save As ..." entry which looks similar, but is used if we don't want to overwrite any existing VI, i.e. exactly the opposite functionality! A small inaccuracy of the mouse can easily select one for the other, with potentially damaging results.

If you don't believe me, create a new VI and place e.g. exponential fit on the block diagram. Double-click the subVI for editing and move one of the terminals by a few pixels. Now go to the toplevel VI and select "file...save All". Notice that the system VI has been re-saved without warning with the changes you just made. If the changes would have been more serious, the entire LabVIEW installation would be corrupted, because it now contains a subVI with altered or broken functionality.

• "save all" is not used very often, so a confirmation dialog would probably be OK.
• "save all" should exclude everything in vi.lib unless specifically told not to.

Here's how the suggested default confirmation dialog could look like.

Idea Summary: The "Save All" menu item should be renamed to "Save All..." and should open a confirmation dialog before the final action is carried out. 

[Dan_Lauber]

For Save All, I'd suggest:

1. First, it performs Save All (this project)

2. Then, if files outside the project have been modified, pop up a dialog listing the libraries with changes and allow the user to Save All, or save individually.  (and a checkbox to not show that dialog box next time)

This prevents a dialog the majority of the time when people use Save All, but pops it up just when you're in danger of overwriting something you may not have intentionally meant to.  My main issue is that if I accidentally save a change to one of my VIs in a library outside the project, I can roll it back using source control, but I don't have vi.lib under source control, so I have no simple way of going back.

For people who edit their vi.lib files, how about using search path precidence like any other development environment does?  So you have the original vi.lib from NI, then if you happen to edit and save a vi.lib VI, it automatically goes into vi.lib_user or something like that, and then if you have a special version you want to use just for a specific project, you include it in a subfolder of that project.  Then to load that VI, LabVIEW does a search starting with the project dir, then vi.lib_user, and finally in vi.lib.

[Terry_ALE]

I do not like save all. It saves unchanged items and when it comes to checking into source code control it makes allowing kind 'noise' that makes it difficult to trace through what actually changed.

[crossrulz]

Terry, if you use the Separate From Compiled option for your VIs that phenomenon with SCC is greatly reduced.

[Terry_ALE]

thanks, I use that setting already

[AristosQueue (NI)]

Terry_ALE, if you use that setting already and you're still seeing Save All save things that have not been directly changed, that's a bug. Please report it to NI.

[Terry_ALE]

I will keep that in mind.  The project almost always asks to be saved ("An Attribute Has Changed") and sometimes other items.

[ZX81]

A little trick:  try to 'Exit' LabVIEW (or try to close a VI) without saving all those VIs that appear to have unsaved changes.  On the 'sure?' dialog, there is a link, "List unsaved changes...".  Check there to see why your unchanged VIs are flagged as changed.  For me, 90% of the time, it is 'recompiled', 'SubVI call modified', or 'a linked VI changed'.  Since I commonly use a VI for both PC and cRIO (and sometimes FPGA) environments, that's so common, I've learned to ignore it completely.

It isn't much help for SCC, though.  Does your SCC have an option to compare binary files before uploading a 'change'?  LabVIEW might be writing an exact duplicate .vi file, with only the timestamp changed.  (I haven't checked LabVIEW, but a few other programs do that.)

[EDIT:  I typed the message above while you posted that you already see its the 'attribute changed'.  I get that sometimes, too, and usually don't know why or how.]

[Terry_ALE]

the 'recompiled' prompt is solved by separating source and compiled code mentioned above

My current SCC is SVN and I have it configured to invoke LabVIEW Compare so I can see that there are no changes.  Going to Git which can be configured that way as well.

[AristosQueue (NI)]

ZX81 That behavior (compiling for multiple environments) is explicitly what is fixed if you enable the Separate From Compiled option on all your VIs. Also known as "source only" setting, because the VI no longer contains the code directly, there's no need to resave when it recompiles for different environments.

https://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/saving_vis_compiled_code/

It is the option used on all new VIs shipped with LV itself since LV 2013 and most older VIs have had it enabled.

I strongly encourage all users to enable this setting always. If it were my personal call, it wouldn't be a setting, it would simply be how LV works, or at least reverse the sense of that setting. Unfortunately, that would break some TestStand use cases that people love.