Public Malleable VI in Packed Library

[raphschru]

Using LV 2019.

I was updating one of my tools library with the idea of converting some public polymorphic VIs to malleable VIs, so the user can fully benefit from type adaptation with these functions.

However when building the PPL (Packed Project Library), I got the error message : "The top-level library you specified contains an exported malleable VI". So it appears it is not possible to export a malleable VI through a PPL.

I understand that a PPL mostly contain compiled code, while malleable VIs are sort of "code templates" which are only compiled when dropped and wired on the diagram.

➡️ So my question is : are PPLs planned to eventually support public malleable VIs ?

I'm not saying that would be easy to implement, just throwing 3 basic ideas :
1. Since PPLs can contain VIs' diagram for debugging purpose, LV would load VIMs' diagram clones and adapt it at edit time (like normal malleable VIs)

2. Internally split PPLs in 2 parts, compiled code and malleable VIs, so PPLs would become an extended container (almost like an LLB, but not editable and atomic). The "malleable part" would also benefit from the same namespacing as the "compiled part" (e.g. MyTools.lvlibp:MyMalleableVI.vim)

3. Have some kind of generic compiled code that can handle dynamic typing for VIMs (hardest solution in my opinion)

If after all, malleable VIs really cannot be put in a PPL, what could be the alternative to distribute VIMs alongside a compiled library ?

(In my case the VIMs are just basic wrappers with the compiled VIs inside, so distributing them alone wouldn't make sense)

- Put the VIMs in another library (e.g. "MyTools-VIMs.lvlib") and add a post-build to put them in an LLB next to the original PPL ? Also, scripting will have to be made to replace library VIs by their compiled version. Lot of work...

- Use source distribution ? (don't know if it would suit, have no experience with it)

Attached you can find a sample project with the explained situation :

- 1 library for normal/polymorphic VIs, which is compiled to a PPL

- 1 library for malleable wrapper VIs

How would you deploy all the VIs so that the output has the least number of files and is the easiest to integrate in another project ?

[crossrulz]

Exported VIMs, as far as I am aware, will not be supported by PPLs mostly due to the fact that the PPL is designed for fully compiled functions.  This is a concern of mine as well.  I haven't gotten to the point where I need to deal with this.  But I am personally leaning towards the LLBs.

[pawhan11]

Did You try to use PPL and library with vims?

We are using ppls for basic components like event logging, error handling and wrapping those in vims would make them easier to use

[bodypillow]

I have tried to use a malleable VI which was built into an LLB by a project referencing that LLB and it doesn't seem to work either.  When you try to drop the .vim into a block diagram from quick drop, nothing happens, and if you browse to the LLB and select it that way, you get a windows "ding" and no action.  This is with Labview 2017.

[GregR]

This issue is very related to why inlining gets turned off on exported VIs during PPL builds. There are 2 main issues.

1. One of the major design goals of PPLs was to be able to incrementally update them. So the design tries to minimize the chances of an update to a PPL invalidating callers. Since any change to an inlined VI invalidates callers, these were seen as incompatible with the goals of PPLs.
2. Making inlining from PPLs work is significant effort. The basic mechanics are all things we do in other places but getting them right involves a lot of corner cases that would be very time consuming.

Malleable VIs have all the complications of inline VIs plus some more. Allowing it is not out of the question but would have to be worth the investment.

Having said that, this doesn't mean that making things public is the only answer. Best practice for supporting malleable VIs for PPL code is to make a friend library. You can then set the extra pieces required by the malleable VIs to community scope.

---

@bodypillow wrote:

I have tried to use a malleable VI which was built into an LLB by a project referencing that LLB and it doesn't seem to work either.  When you try to drop the .vim into a block diagram from quick drop, nothing happens, and if you browse to the LLB and select it that way, you get a windows "ding" and no action.  This is with Labview 2017.

---

I'm not sure what you mean by building into an LLB. If you just mean you moved the files into an LLB, then that should be fine. If you did this through a build that removes block diagrams, then the resulting malleable VI will not be usable. How exactly did you create the LLB?

[bodypillow]

---

@GregR wrote:

---

@bodypillow wrote:

I have tried to use a malleable VI which was built into an LLB by a project referencing that LLB and it doesn't seem to work either.  When you try to drop the .vim into a block diagram from quick drop, nothing happens, and if you browse to the LLB and select it that way, you get a windows "ding" and no action.  This is with Labview 2017.

---

I'm not sure what you mean by building into an LLB. If you just mean you moved the files into an LLB, then that should be fine. If you did this through a build that removes block diagrams, then the resulting malleable VI will not be usable. How exactly did you create the LLB?

---

I built the LLB as a source distribution from a project (Destination type = LLB) with the following settings:

I verified this on a few different malleable VIs across a few source distributions in different projects.  Seems to be pretty constant behavior.  My only workaround so far has just been to separate the malleables into a separate folder and just distribute them as bare VI files instead of being built into the LLB.

[GregR]

---

@bodypillow wrote:

I verified this on a few different malleable VIs across a few source distributions in different projects.  Seems to be pretty constant behavior.  My only workaround so far has just been to separate the malleables into a separate folder and just distribute them as bare VI files instead of being built into the LLB.

---

I tried to reproduce this in both 2017 and 2020 but both seem to work fine. If you try to open the malleable from the LLB instead of dropping it, what happens? If you haven't filed a bug report, please do.

[bodypillow]

I couldn't reproduce my issue with a toy project / LLB / caller setup either, so I tracked the issue down in our normal production spot to the standard Post-build action VI we used to password protect items in the LLB.  Apparently this is not compatible with VIMs.

Even when it does not load when you try to drop it in a block diagram, it will still allow you to open it from the LLB and view the front panel, run it, and even enter the password to view the backpanel.  But it won't allow you to drop the item into the backpanel of a caller VI.  I guess this is a known behavior of malleables:

https://forums.ni.com/t5/LabVIEW/Malleable-VIs-Password-Protection-amp-LV-Upgrades/td-p/3936669

[GregR]

The code explicitly breaks password protected malleable VIs. I'm still looking into why. Also if they break when password protected, why do we allow them to be password protected? Might be better for setting a password to fail rather than creating an unusable file.

I'll try to come up with an explanation but for now you should definitely not put passwords on malleable VIs.

[bodypillow]

---

@GregR wrote:

The code explicitly breaks password protected malleable VIs. I'm still looking into why. Also if they break when password protected, why do we allow them to be password protected? Might be better for setting a password to fail rather than creating an unusable file.

I'll try to come up with an explanation but for now you should definitely not put passwords on malleable VIs.

---

Just to clarify, you are saying that you were able to reproduce the issue presented by my little password protecting code that I screenshot?  If so, I apologize as I should have uploaded the VI or snippet so you didn't have to duplicate the code.

If it is truly malleable VIs, and not inline VIs, then a possible workaround for me would be to skip files based on the *.vim extension, but I'm not sure (haven't used a non-malleable inline yet).