LabVIEW
LV 2020 Upgrade Note: Altered rules for named Bundle and Unbundle inside malleable VIs
The following information was accidentally left out of the final draft of the LabVIEW 2020 Upgrade Notes. Even though we are still some time away from the release, I am posting this information publicly so that the URL can be included in supplemental documentation.
LabVIEW 2020 alters the name-selection rules for Bundle By Name and Unbundle By Name nodes used inside malleable VIs. This fixes a bug but may break some upgrading VIs.
The following information affects Bundle By Name and Unbundle By Name nodes whether standalone or on the borders of an In Place Element structure.
Summary: The rules of what happens with bundling and unbundling when you wire different clusters or classes to a malleable VI input terminal have changed. In the vast majority of cases, this will fix bugs. In a limited use case, it may break previously working VIs, necessitating a manual fix from you.
The new behavior is that named bundle/unbundle nodes in the subVI call will always either find the same element name as the original malleable VI or else reject the wired cluster and break the caller.
Details:
When you change the upstream type of a cluster going into a Bundle By Name or Unbundle By Name node, the node tries first to find an element of the same name as it had previously. But if there is no such name, then the node then tries to do a “best match” using a complex set of rules. These rules are generally regarded as very helpful when editing a VI. Those rules are unchanged in LV 2020, regardless of whether you are editing a regular VI or a malleable VI.
But when you call a malleable VI as a subVI, the malleable VI gets instantiated: the malleable VI serves as a template for a new VI that uses the types you wire to the call. This new VI is the one you see if you right-click on the call and select "Convert Instance VI to Standard VI".
The instance needs to always find the same name as the original or else reject the wired cluster. In LV 2019 and earlier, the nodes in the instances were still doing best-match as a fallback, which resulted in seemingly random behavior where successive type changes would result in different element selections depending upon the order of edits in the caller. In LV 2020, the nodes now demand the same name as the original, always. In most cases, this will make callers of malleable VIs much more reliable, but it may break some code that used to work because it happened (randomly) to do what you wanted. R&D considered ways to maintain those situations, but we found there were rare situations where the wrong item was selected and the node was not broken, a situation we considered very bad. We chose to break so that cases that are compiling that were not actually doing what you intended will properly break.
Example:
Suppose this is your malleable VI. It unbundles an element named "1" from the input cluster:
In LV 2019, this caller is unbroken because the instance finds the nearest best match, but whether it found “2” or “3” depends upon the order you did the wiring. Even when it did what you intended, it was only because you got lucky. That inability to know how the template was instantiated is why this bug had to be fixed and why there is no mutation possible to keep your code working.
In LV 2020, broken because there is no element named “1”. You will need to add an element named “1” or rename an existing element to fix this code.
