If the subVI is unrelated to the topic being exemplified, I don't see a problem with this. In this case, if seeing that subVI diagram is key to understanding how to call a DLL (the topic of this example), then I agree with you. But if the subVI's diagram is unrelated to showing how to call a DLL, I disagree. There are plenty of useful APIs that have password protected VIs.
And then there's the case where the example is showing how to call an API. If the API itself is password protected, this rule would keep us from shipping any examples of using that API.
Are some VI's password protected because, not long ago, scripting was private?
Secondly, let's take the example in the picture, why is that VI protected? When using that example this morning, I liked the way the interface allowed me to open VI's, so I wanted to check out how you they did that. Denied!
I got a CAR from a customer about that very VI, and I unpassword-protected it in LabVIEW 2011 because it doesn't contain any private functionality. I think the majority of cases like this could be handled with CARs instead of an Idea Exchange entry.
I should also point out that this subVI is in the examples folder...I agree with Stephen that APIs that live in vi.lib could legitimately contain password-protected VIs. But for subVIs in the examples folder, I agree with Broken Arrow that they should not be password-protected.
There have been people sweeping through over the last two versions of LV and removing passwords that are no longer needed because of scripting. There's still more to go -- it's quite a backlog.
We scrubbed all of the LabVIEW Core examples (along with several modules/toolkits) in LabVIEW 2013 to adhere to a new example style guide. One of the requirements is that no VI that is part of an example can be password-protected.
