@AristosQueue and anyone else
I am looking over the LV 2019 Malleable VI example code after NIWeek 2019 and while watching the video recording from the presentation.
I came up lesson Malleable VIs - 2b.vi where two classes are created, one with a built-in equals function and one without. The one with the built-in function is supposed to call the built-in equals function code from the class and thus find the DeF in the def element of the stored original array. Mine is returning -1, not found on both classes.
Anyone have this working?
I tried the example you mentioned and got the same result.
The problem appears to be in the Type Specialization Structure for the Search Unsorted 1D Array.vim.
The first case is listed as the following:
Unbroken for LV Classes that have an Equals.vi method defined. Use this case even if there is a custom compare function passed in -- either the class will use its custom sort or the custom function will be used. Either way, this class will not use the built-in primitive for sorting.
However, it calls directly the Equals.vi of EqualComparable.lvclass.
If you replace this with the Equals.vim (found in the Search Unsorted 1D Array Core.vim), then the VI behaves correctly.
I think this is the expected outcome and it appears to handle the two cases (has Equals.vi with appropriate conpane, does not have Equals.vi) correctly.
I'm not exactly sure why this is the case - it appears the output of the Index Array doesn't correctly propagate maybe?
Hopefully AQ can explain what's going on...
I tried to be thorough and also checked my LV 2018 shipping example code on my other system, and this Lesson 2b.vi worked out of the box for the top VI to find the element by using the classes built-in Equals.vi
There appears to be an issue with the LV2019 implementation.
The code seems to be the same, but the equals.vim has a different icon background color, despite the code looking the same, so something was changed between '18 and '19 in this code that is causing this issue.
The LabVIEW 2018 version has the Equal.vim located in the folder Nested Malleable VIs, whereas in the LabVIEW 2019 example the Equal.vim was moved to VI.lib
I am trying to ascertain any difference between the two.
Replacement of the VI is incorrect. In LabVIEW 2018 the code runs correctly and leverages the class built-in Equal Method. In LabVIEW 2019 this is not occuring. The code is the "same".
I'd suggest taking a look at the first point under the "Upgrading from LabVIEW 2018" section in the 2019 Upgrade/Release Notes.
The behaviour of the TSS changed and now broken SubVIs are allowed in a frame.
There is no broken VI - so I fail to see how that point applies?
The Malleable VIs are supposed to adapt to Class and leverage methods in a class with the same name. In this instance the VIM is supposed to call the Equals VI from within the class since the class contains the properly named and unbroken VI. If the class wired does not have an Equals - the VIM utilizes the built-in search function.
The same code is presented in the Example code - nothing is broken, the Malleable VI is not leveraging the named method VI. The correct case is selected by the compiler in the TSS.
Ryan - what happens in LabVIEW 2018 when you right click on the Malleable VI and choose "Convert Instance VI to Standard VI". Does it select the correct class VI? In 2019, it doesn't (but it does when you use Equals.vim)
Yes, when I drill down the nested VIMs and convert to instance on each one, at the last VIM it converts to select the correct Equals.vi (the top thread for the class with the built-in equals).
I'll post the screenshots of the drill downs for 2018 and 2019