Class member VIM breaks PPL compilation in 2019, works in 2017

[cbutcher]

Interesting read regarding VIMs in PPLs: Malleable VIs in Packed Project Libraries.

My situation:

• I have some library containing a couple of classes, one of which contains a public-scope malleable VI.
• The VIM doesn't access class data
• In LabVIEW 2017, this compiled to a PPL fine
• In LabVIEW 2019, I'm given an error message with the text "You did not specify a top-level project library or the top-level library you specified contains an unsupported malleable VI."
• Moving the VIM out of the library allows compilation (because really it doesn't contain any class-specific code, so it needn't be a class member or even a library member)

Is this expected behaviour? The workaround in this case is simple, but I'm unsure why it previously worked and now fails. I'm glad the error message was at least suggestive of the problem though.

The malleable VI and a screenshot of an example caller are attached.

[Y.Ueno（退職）]

Hi cbutcher, 

I think it has a linking issue because of upgrade and similar issue with below page. Could you check it? 

• Dynamically Called SubVI Does Not Load When Built into Executable

[cbutcher]

Ueno-san,

Thank you for this information. I read the article that you linked to, but am not sure if or how it applies to the situation I described.

I didn't see a version mentioned in the article but note it was updated in May 2018 - should I read into this that you're suggesting changes to the linker in LabVIEW 2018 are responsible for modifications to the handling of VIMs? 

My SubVI calls are all statically linked in this case, but perhaps you mean that malleable VIs behave in a similar way to dynamic linking? Without a more detailed understanding of the internal workings, I couldn't do more than guess at that.

Thank you again for the information, although it still doesn't really tell me if there is some intended change in behaviour or if this is a bug.

[Y.Ueno（退職）]

I'm not sure about your class VIs,  malleable VIs relationship in PPL. Could you make very simple reproductive example project? I will try to check the behavior. 

[cbutcher]

I can post an example later when I have a computer available but I think I've worked out at least why it can't be done now. Perhaps previously it was excluded but didn't trigger the error.

When the VIM is part of the library (I think the class is irrelevant in this case, but I haven't checked that), and has public access scope, LabVIEW should try to make it available to callers of the compiled PPL. However, I'd guess that actually this doesn't make much sense - what is a compiled inline VI without its caller?

Once I move the malleable VI out of the library, it no longer forms part of the API and so can be cleanly compiled into the library (class) VI(s) without concern that it might be needed with different datatype.

[Y.Ueno（退職）]

It can not be determined because it can not be reproduced, This issue may correspond to the rare case of the upgrade mentioned on the following page.

• Forcing a VI to Recompile

There is some Caveats and Recommendations for Packed Project Libraries in this Help page, and mentions about including classes like below.

Spoiler

If an exported VI has a connector pane with inputs or outputs of type definitions or classes, include the type definitions or classes in the top-level project library. When you right-click a project library and select Replace with a packed library from the shortcut menu, LabVIEW does not replace type definitions and classes, only exported items of the packed library. As a result, VIs in the packed library might break when you replace the project library with the packed library.

If the error occurs after upgrading as recommended on this page, please attach the 

reproductive project.