"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. 

[fabric]

I use Save All often enough that a dialog would be annoying, but I agree that system VIs need to be better protected. I like the crossrulz variation the best: lock vi.lib and it's mates.

[AristosQueue (NI)]

Previously I said that as a member of LV R&D, I didn't see any technical barriers to this idea. I take that back.

Two solutions have been proposed for the core issue of "help us not overwrite vi.lib"

a) A dialog box when you do Save All

b) Mark the VIs as read-only on disk.

Making vi.lib read-only would have bad impact on service pack releases -- it would require us to rekit the whole vi.lib since recompiles would no longer bring VIs up-to-date. And toolkits installed after LV would have to be unlocked and formally mass compiled. That's why we've shied away from that solution in the past.

A dialog box that appears only for VIs in vi.lib seems like the best approach to me. But then I realized that doesn't close the holes raised by the core issue.

Smaller issue: Someone mentioned both instr.lib and user.lib. Both of those directories are much more commonly written to by users directly and deliberately. Impacting them with this dialog seems bad. Maybe. Thoughts?

Bigger issue: What would you do with the "Save Changes" dialog? Sure, hitting Save All we could intercept, but when you close a VI, it unloads and offers to save that VI and its subVIs. Same with closing a project. Would we break the vi.lib VIs (and maybe instr.lib and user.lib) out as a separate Save Changes box? Adding more checkboxes/options to that dialog is a non-starter -- we've already got issues with its complexity as it stands despite many years of finding small ways to simplify it.

Moderate Issue: What about legitimate changes to vi.lib resulting from service pack installations? We've been known to ship modified typedefs or subVIs with new conpanes and expect callers to gracefully update. Yes, LabVIEW now uses "source only" our files, which *mostly* dodges the need to save changes, but not entirely. And there are third parties that install into vi.lib that do not use "source only". How to handle them? Surely we don't want you to get a dialog every time you run LV, so I think there needs to be some way to accept those changes.

Smaller issue: Does anything have to be done to the programmatic method for Save All? Does anything have to be done to Mass Compile if you happen to have a changed vi.lib VI in memory when you run Mass Compile?

http://nitalk.natinst.com/thread/52567

[JKSH]

Regarding service packs and installations: How about a "system update" flag? The VI Server/LabVIEW IDE can prevent users from modifying vi.lib/instr.lib/user.lib under normal circumstances, but permit it during an installation/upgrade. It could also be a hidden, advanced option that grants access to NI R&D or power users, but only when they've explicitly requested it (and by extension, claimed responsibility for any accidents that break their system).

For those who want to develop instrument libraries and user libraries, have them save their development files externally and deploy/upgrade into instr.lib/user.lib through the IDE, VIPM, or other installer. (Anyway, Microsoft is strongly discouraging users from modifying the contents of C:\Program Files\ and its subfolders directly)

Regarding legacy installers that place old versions of compiled VIs in *.lib, a once-off dialog should be ok (to confirm that the user wants to enable "system update" mode to re-compile)

[JÞB]

Interesting discussion.  here is my take.

Instr.llb, templates, User.llb(except _subfolders) These I HAVE source code control for. underbar subfolders e.g. _probes need some training for adoption.  Not one I'm pushing today

errors.  again any custom errors for this groups components are in SCC.  (That's what the readme file in errors is for, so we can track our "error budget")

examples.  do not go in SCC--yet  (well not here- they do in my happy place) and this is potentially MORE harmful than playing around with things in vi.llb

wizards & projects, These are often 3rd party packages I should be able to track and fix any corrupted packages with VIPM.  If I put something there I'd add it the SCC.

That leaves a lot.  Let me put 1000 words on it

Thats a lot of stuff that can go wrong (I wound up with a bad icon editor once or twice that I needed to reload from a safety copy) in a lot of places I want access to.

I would LOVE a default ini section that lets me lock down vi.llb and examples.  I have a few people in mind who need their ini hacked in just such a manner. (and one to "Prevent saving from previous" while I'm at it just to save a few hypertension pills.)

Is SOMETHING needed,  probably- but we must recognize this feature would be like "training wheels" for LabVIEW or, like the driving instructor's passanger side break pedal.  Useful to prevent costly mistakes until and unless you need to get some serious performance out of highly skilled developers.

[AristosQueue (NI)]

Someone around the office made the suggestion to ban editing of VIs in vi.lib/user.lib/instr.lib entirely. Those VIs would be modifyable only by explicitly overwriting them on disk through a conscious Save As of another VI (or VI hierarchy). If the VIs aren't editable in memory at all, then any changes made are purely the result of programmatic changes resulting from upgrading a toolkit or applying a patch, so LV would just automatically save all such changes. The VIs otherwise would never show up in the Save Changes dialog and there'd be no risk from a Save All.

I can see pros/cons to this approach. I figured I'd post it here as one possible solution to the problem.

[Manzolli]

VIs shipped with LabVIEW and libraries made by someone else could have a lock. If you want to modify, make a copy! I did when the VIs "Write To Spreadsheet File" and "Read From Spreadsheet File" used Single data and I need more precision. I did a copy and changed both VIs to work with Double, modified a little the icon, updated the documentation and placed at User Libraries palette. Never saved over the NI originals VIs.

Agree with LordNobady, we need a protection to a non intentional save to some VIs, like the system ones. I have no problem with the current behavior of the Save All command and use it quite often. An optional confirmation box will help, but is not sufficient, since we could could choose the wrong answer after answering many so many times “Yessssss...”. Sometimes we may want to save some, but not all VIs, which ones yes?

I believe that the best solution goes towards a method (ease to manage) to protect some VIs. If you open a locked VI, when you intend to save it (alone or in Save All) the system may show a box with this message “abcde.vi it's locked. Save as...” and ask for a new name. Of course, LabVIEW shipped components should come locked by default.

[altenbach]

> Someone around the office made the suggestion to ban editing of VIs in vi.lib/user.lib/instr.lib entirely. Those VIs would be modifyable only by explicitly overwriting them on disk through a conscious Save As of another VI (or VI hierarchy).

Good luck with "Save as"! Have you actually tried this?

This raises the issue that I have complained about many times in the past: "Save As" is greyed out for most VIs in VI lib.!! 😞

Scenario: Let's say I want to write my own nonlinear curve fit and want to keep it "pin compatible" with the existing version from the fitting palette. I open the VI and "gut " it, keeping only the connected terminals. Now I want to save it under a new name in my own hierarchy for later use and further development. Bzzz! Cannot do it! "Save as" is greyed! Grrr....!! All that work for nothing!

Of course if at this point my mouse slips and I select "save" or "save all" (which are both NOT greyed out!!!), I probably need to reinstall LabVIEW to fix the mess. This situation is clearly not ideal and needs to change.

The reason of course that the VI is part of a lvlib. I believe that restriction needs to be relaxed.

(and maybe that should be a different idea here. agreed?)

This is so backwards: We cannot do what we want to do, but we can easily do what we should NOT do under any circumstances!

[Thoric]

I recall, as a fledgling wireworker, that I found the ability to edit the included VIs very dangerous. I always relied upon the basic vi.lib package as being absolute, but often I would be called to someone's desk to assist with a peculiar 'bug' in their code only to eventually find that they'd completely mashed up a VI from vi.lib. The usual fix was to get a copy from someone else's installation, but how nice it would have been if these VIs had been protected in the first place.

I agree that the standard NI-distributed functions should be protected until un-protected by some determined action of the operator. Remember how C:\Program Files in old XP would show as "These files are hidden, are you sure you want to view them?" - and of course you would click Show to go rootling around in there, but you knew you couldn't mess about for fear of rendering Windows inoperable.

The vi.lib folder should be protected.

[BPerlman]

I use Save All a lot.  I wouldn't want the message box.

The other two parts of the idea I do like though 

-- changing the Save All menu item to look more different than Save As

-- protecting vi.lib and such from accidental changes.

Can this be made into two different ideas so we can vote for the protection without the message box?

Batya

[ZX81]

I understand the implications behind making the files in vi.lib (or instr.lib) read-only.  And I agree that isn't a great option.  Manzolli already pointed out that NI could simply make all vi.lib .vis "Locked (no password)" by default (see .vi properties/Protection).  This thread is 2 years old, and I still don't see it adressed.

My biggest case for a fix comes from opening a customer's .lvproj on my development environment.  About 50-80 .vis in the vi.lib were suddenly changed.  This case was because their project had duplicates of nearly 100 vi.lib files (obsolete by about 5 revs), and other vi.lib files (not in their project) were automatically re-linked to reference this project.  Later, when I tried to work on another project, all the links were messed up.

A second case is if I want to send sources to a customer.  It may only work on my machine, because only mine has a vi.lib change they will never see.  If I make them change their vi.lib, it may break other projects they use.

Like Manzolli said, if you change it, copy it to your local project.  But LabView Development should push you to do that, not prevent you.

I think altenbach is describing a related scenario that is important to consider.  If I want to modify a vi.lib .vi that is called by other vi.lib .vis (like a best-fit), how is that handled?  Currently, each .vi knows links to all its sub-.vis.  So, if I try to copy one into my own project, it is a conflict, and would change the links in the other vi.lib .vis that call it (see my own first case above).  That's bad.  So I think the very first step NI needs to take is:

Put sub-.vi linkages in the .lvproj file.  And use those linkages to override linkages in a .vi (without modifying the linkages in the .vi).  .vi files still need linkages for sub-vis, in case they are opened outside a .lvproj and for initial access, but the .lvproj would override them.  That may also mean that the compilation of many .vis will need to be tied to the .lvproj or put in some other folder (i.e. ./auto-dependency).  (I have never separated the .vi definition and compile, but isn't there an option to do that already?)

Later, after that has been proven out, NI could take the second step, and lock out changes to a vi.lib file (or "Are you sure?").