Malleable VIs, Password Protection, & LV Upgrades

[paul_cardinale]

This one just bit me.

Ordinarily, if you apply a password to a .vim, it breaks (I hadn't known that).

However if you apply a pw to a .vim programmatically (using the "Lock State.Set" method) and then manually save the .vim, it will be password protected and not broken; it will work fine ...  until you load it in newer version of LabVIEW; which will cause the .vim to break.

[wiebe@CARYA]

Malleable VIs (.vim) cannot be password protected because their calling VIs need to copy and modify the block diagram of the malleable VIs for different input data types.

---

It's hardly different from a normal inlined VI. Those can be PW protected.

Obviously, LV is capable of copying, reading and compiling PW protected diagrams. Modifying shouldn't be too hard.

It's probably the level at which the vims operate that doesn't allow this.

It's sad, as vims would typically be so 'magical' that you would want to avoid <CLD level users modifying them (by accident).

This reminds me of the "allow printing" option in PDFs. The spec literally says that readers are asked to respect that option...

[AristosQueue (NI)]

No, it's a conscious decision to prevent VIMs from having a password. Inlined VIs are not modified code from the original; VIMs are modified. Password would essentially prevent the caller from seeing how the VIM is responding to their own data type, removing a primary mechanism for callers to debug code, far more problematic than the inlined VI blackbox. And it would prevent "disconnect from VIM" from working, which causes a problem for building apps. All in all, I (and my team) did not see it as reasonable to distribute a template that has to be filled in and then block people from seeing the finished template code. You're free to write up an Idea Exchange entry if you want to change that.

I'll file a bug to break the VIMs on load if they've been created by file extension change.

[wiebe@CARYA]

---

@AristosQueue (NI) wrote:

Password would essentially prevent the caller from seeing how the VIM is responding to their own data type,

---

Is that the purpose of password protection 🙄... To prevent callers from seeing how the VI(M\T) is responding (to whatever input)?

---

@AristosQueue (NI) wrote:

And it would prevent "disconnect from VIM" from working, which causes a problem for building apps.

---

I'm sure that's not hard to solve 😂.

The real problem is that this would be done through an API. That API would be exposed so we could all do that.

---

@AristosQueue (NI) wrote:

 All in all, I (and my team) did not see it as reasonable to distribute a template that has to be filled in and then block people from seeing the finished template code. You're free to write up an Idea Exchange entry if you want to change that.

---

I don't normally use PW protection at all, but .vims specifically could be puzzling for beginners. I prefer educating them over hiding things from them. But I can see why one would want to PW protect esp. .vims.