At present, using a malleable VI in almost any form alongside PPLs seems to be largely impossible.
Of course, a malleable VI is a template of sorts, and a PPL is the compiled form of some library. I can see this makes including the malleable VI impossible (at least without a predefined list of allowed types, at which point you could use the VIM as a private VI and define a set of public or private VIs, then call those from a public polymorphic VI).
However, it would be nice if we could define a VIM (either in, or alongside) a library in a project, and have it be placed in e.g. the Support destination (or specified destination via the Build Specification settings).
A quick attempt to do this resulted in the following:
- Create a library with two VIs, one outputting a number and the other a string.
- Create a VIM that has an input used only for type matching, and a Type Spec Structure for Assert Structural Match on string, int32, output the appropriate matching result type from one of the two (public, in this simple test) library VIs
- The first case of the TSS is the string one (seems relevant to outcome).
- Build the library into a lvlibp, with the VIM set to Always Included, and the destination set to Support.
- The output files are A.lvlibp, Output String.vi, Get Value.vim.
- A.lvlibp only contains Output Num.vi, not the string anymore.
- The VIM is not loadable via project (although it opens broken alone), because it calls A.lvlibp:Get String.vi, which doesn't exist.
- Get String.vi is unloadable, seemingly because it requires (perhaps it expects to be) A.lvlibp:Get String.vi...
Could this please be improved? 🙂
Ideally the VIM that is placed in the accompanying destination should link to the VIs in A.lvlibp, and none of the VIs should be missing in that PPL.