Option to open VIs or projects for viewing only ("locked" or "read-only")

[SFK]

When reviewing old projects or VIs, the "VI changed" title bar star is always only a few mouse clicks away. And beware of accidentally opening an old project with a newer LabVIEW version!

You all know the "vi has unsaved changes" dialogs that follow when just wanting to close the windows, and who has not at least a dozen times saved an old VI in one of these situations just out of a misplaced click or the habit to save your code whenever you you are prompted to...

This is why I propose a new file menu entry: open (locked)... or open (read-only)... or an "open options" control in the file dialog.

Its functionality would be to open the selected file or project in a similar way like the locked VIs: you can look at them, browse through case or event structures, but cannot change a thing...

Even better would be the option to allow changes (e. g. move/delete some portions before selecting the rest for copy&paste), but to prevent re-saving the file under the same name. For this case, trying <CTRL-S> or closing the file would open a dialog stating that the VI was opened as "read-only" and that you may either discard the changes or save the file under a new name.

Of course, this "read-only" flag would be inherited to all subVIs, typedefs etcetera that would be opened from the original project or VI.

And to make my whishlist complete, a color coding of the VI window / project frames would signalize the read-only state of the code:

By the way: Wouldn't it be nice if VIs in vi.lib featured this opening mode by default?

Best regards,

Sebastian

[LukeASomers]

I would extend this not only to VIs in vi.lib, but any VI not in the project. If I wanted to change the VI, I'd put it in the project or open it outside the project.

[SnowMule]

Why's it matter if it's checked into source control?  😉

I would suggest better handling of read-only objects when there's been changes made to them.  If SCC is hooked up in the project things generally go well.

[LukeASomers]

Were you talking to me? Projects have many other uses besides source control. Principal among them is providing a bright line between project insides and project outsides. There is a difference between a project member and a project dependency.

In particular, project dependencies can be dependencies (or elements of!) another project. These other projects are likely to suffer if their dependencies/members are changed by some outside project.

[Manzolli]

I had this problem many times since I don't use virtual machines yet.