LabVIEW
Lock VI.Lib User.Lib VIs
So recently I found myself accidentally editing some VIs in my user.lib. They were some reuse VIs that I was making a copy of to edit, and instead of editing my copy I edited the original. Because of this I went through and made all reuse VIs locked but with no password to help others from making the same mistake.
So now when the reuse library is installed and a user opens, they will need to unlock it before editing. Not a big deal and it isn't hiding anything behind a password. But it got me thinking, should NI do something similar with their VIs? Is this one step to help users from editing these files? Is it not necessary? And can anyone think of any draw backs to mass locking a reuse library.
The simpler solution is to make them read only and hit the ini option to treat them as locked. In Fact, your SCC does this already. Unless you check out the library you intend to edit, the files will be read only. That ini setting is one of my favorites and has saved me many headaches.
Depending on where I am- vi.llb gets set to read only and some user's are handed ini files that contain the treat read only vis as locked flag set and told to never ever change it or "Pain there will be pain!" and I've been known to have a vi.lib back-up on a thumb drive on my key-ring! (Some users just have to learn the hard way!)
Onto the next observation: if you are making a copy of a reuse vi to edit you probably saved it with the wrong extension in the wrong location. it belongs somewhere in templates as a vit. 
This was briefly discussed over in the Idea Exchange: "Save All" needs a soft barrier to prevent accidental use
@JÞB wrote:
The simpler solution is to make them read only and hit the ini option to treat them as locked. In Fact, your SCC does this already. Unless you check out the library you intend to edit, the files will be read only. That ini setting is one of my favorites and has saved me many headaches.
Depending on where I am- vi.llb gets set to read only and some user's are handed ini files that contain the treat read only vis as locked flag set and told to never ever change it or "Pain there will be pain!" and I've been known to have a vi.lib back-up on a thumb drive on my key-ring! (Some users just have to learn the hard way!)
Onto the next observation: if you are making a copy of a reuse vi to edit you probably saved it with the wrong extension in the wrong location. it belongs somewhere in templates as a vit.
I didn't fully explain my situation. This VI is not the kind of thing that I would want a VIT for. It was a utility VI that I wanted to see if I could improve so I wanted to save a copy elsewhere, as a new VI then edit it and compare the performance to the one in the user.lib which I expected to be untouched.
I started by setting all files to read only. This is faster then having to open a reference, edit, and resave the VI. But as soon as installed the reuse library on a new version of LabVIEW it had to mass compile, which it had problems doing since I couldn't resave the file. Part of the package making process involves opening references to update description and such so I already have the reference open. Adding the Lock to the VIs I wanted didn't seem to add much overhead.
Thanks for the link to the Idea exchange I did a search on locking VIs but that didn't come up. The discussion is very interesting since I use Save All quite often.
Edit: Oh geez. I event commented in that idea exchange shows how much I remember.
Some things to consider to reuse libraries:
Separate Compiled Code - then you don't have to save overtop of VIs. Just the compiled code goes into the object cache.
VIPM should now (possibly released with 2014) allow you to lock the VIs in a package with or without a password. You don't have to deal with it then as part of your release. VIPM can do it all for you.
Inlining might be another thing to look into to avoid the mass compile issue.
@crossrulz wrote:
Some things to consider to reuse libraries:
Separate Compiled Code - then you don't have to save overtop of VIs. Just the compiled code goes into the object cache.
VIPM should now (possibly released with 2014) allow you to lock the VIs in a package with or without a password. You don't have to deal with it then as part of your release. VIPM can do it all for you.
Inlining might be another thing to look into to avoid the mass compile issue.
Thanks for all of these suggestions. I have implemented them already in some use or another.
I already seperate compiled code on all reuse code. Which is why I was confused when it needed to resave a read-only file and that's when all of this fell apart. I'm guessing this might be a sign of a bigger issue like why it thinks the file on disk needs updating.
I already inline all VIs when possible. I even thought about re-writing all the OpenG stuff to take advantage of this but instead I'll just be happy with it the way it is.
I don't use VIPM 2014 yet, but I do use the Pre-Build functionality of VIPM which updates documentation, turns off debugging, turns off, automatic error handling, seperates compiled code, and locks the VI. I had this be part of the Pre-Build instead of Post-Install because I want the install to take as little time as possible. Right now our VIPC is over 46MB (OpenG, NI, Internal and other External packages) and I don't want to make the install process to take more then it already does.
