Search the Community

I have seemingly found an issue with the shipping example code for Nested Malleable VIs. Another user has verified that he saw the same behavior in 2019. I am working through the examples and the presentation from NIWeek 2019. In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed. When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi. One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same. The Equals.vi code looks identical, and the calling VIM look identical. I posted on the LabVIEW NI.com forum here: https://forums.ni.com/t5/LabVIEW/LabVIEW-2019-Malleable-VIs-Shipping-Examples-Lesson-2b-Nested/m-p/3966044/highlight/false#M1129678 I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.

Has anyone found any properties or methods associated with malleable VIs? Specifically, I was hoping to find a way to invoke the "Convert Instance VI to Standard VI" function after confirming that a selected VI was indeed malleable. LabVIEW reports the class type of a selected malleable VI on the block diagram as a standard Sub VI, and I didn't see any properties/methods under the VI class. I'm exploring what it would look like to make a utility to convert a malleable VI into a polymorphic VI for the purpose of backwards compatibility. I'd like to have a reference library that uses malleable VIs but create a version that is still accessible to someone using older versions of LabVIEW that don't officially support malleables.

For those who have been playing with malleable VIs, the Type Specialization Structure has probably become a common sight and much abused tool. The basic use of it is that if the action it performs is meaningless given one of the inputs, the included code will break and the next case will be tried. This is great, but sometimes, it can be difficult to think of all possible variants of an action, and in particular, if the action needs to be different for two or more types, but two or more types are compatible with different codes, how to make sure which code will be executed with what type? Enters the Types Must Match function: I found this little gem in... Hidden Gems, within an odd-looking VI which I felt compelled to check out, Debug Write.vim Open its diagram and light will shine, opening grandiose vistas and parallel universes remaining to be explored. Of course, as the comment on the diagram says: "This structure and the type-testing primitive functions it contains are not public LabVIEW features. They are experimental and should not be edited, copied, or used in other VIs without conducting extensive testing. See Context Help for details." Here is the context help for Types Must Match: My apologies if this all well-known among expert users, but I couldn't find it mentioned otherwise on the site...