LabVIEW botches unbundle when cluster is changed

[Wiebe@CARYA]

>
>  I believe this bug is in most of the LV 8 versions. The
situation that leads to this issue is when there are two or
more elements in a cluster that are of the same data type and the
cluster containing them is configured such that the two or more elements
follw each other in the cluster order. When an element is deleted the new
(wrong) field is now at the same index inside the cluster and is of the
right data type so the "switcheroo" happens. 
Thanks Ben.

I never noticed this happening to me. That could mean all of my applications
are bugged!

When I edit a cluster, I remove elements, then apply changes, and then add
elements (then apply or simply close the type def). Perhaps thats why I
never have this problem...

>Editing the type def with the callers closed minimizes the
occurence. I hope that help, Ben

So it doesn't happen always?

Regards,

Wiebe.

[Ben]

---

Wiebe@CARYA wrote:

>
>  I believe this bug is in most of the LV 8 versions. The
situation that leads to this issue is when there are two or
more elements in a cluster that are of the same data type and the
cluster containing them is configured such that the two or more elements
follw each other in the cluster order. When an element is deleted the new
(wrong) field is now at the same index inside the cluster and is of the
right data type so the "switcheroo" happens. 
Thanks Ben.

I never noticed this happening to me. That could mean all of my applications
are bugged!

When I edit a cluster, I remove elements, then apply changes, and then add
elements (then apply or simply close the type def). Perhaps thats why I
never have this problem...

>Editing the type def with the callers closed minimizes the
occurence. I hope that help, Ben

So it doesn't happen always?

Regards,

Wiebe.

---

In my experience once you it happens I can go back to backups and recreate it. I have avoided deleteing elements or used the method above to avoid it so I am not getting slammed by this behaviour (as far as i know!).

Ben

[Ben]

Judging based only on public reports of this bug (this is the first public notice that I am aware of)

the occurence of this bug is extremely rare.

Ben

[jdoyle]

Wiebe is correct. By deleting one member, applying changes, then adding the new element and applying changes again, the references to the deleted element in in-memory VIs turn black and break the VI.  This is at best a work-around because any VI not in memory when this is done will suffer the original problem when it gets loaded. As to the frequency of this problem, I can't speak for other projects, but this problem affects us frequently.  We appreciate that a CAR has been created for this and we are looking forward to having one less way of creating bugs in our code.

[Roy_F]

---

BCho wrote:  CAR #153461 has been filed on this issue. You can use this number to track fixed issue in future releases of LabVIEW.

---

For those wishing to track, the above CAR was closed as a duplicate, use CAR# 117209 instead.

Roy

[cebailey]

My project is beset with unbundle nightmares, apparently of the form discussed here. My project passes a cluster of clusters including refs and values through dozens of vi's, and every day something else breaks when various elements are reselected. I'm moving more and more things into globals and unnamed clusters, because these don't keep changing. The advantages of named clusters turn to dust if the clusters keep reselecting their elements. This is happening inside clusters I haven't touched in months, perhaps because they are clusters within my supercluster and I change other clusters inside that.

I've been considering trying to create an unnamed cluster where the first element is always an array of strings that identify the remaining elements, and trying to think through how to automate the disassembly of this cluster on the receiving end. It sure would be great if named clusters were robust - it's hard to predict how much more trouble and how many more delays my project will see.

Sorry, but - what is a CAR? Is there a name for this bug? How do I look for news about it?

Thanks!

[Ben]

---

cebailey wrote:

My project is beset with unbundle nightmares, apparently of the form discussed here. My project passes a cluster of clusters including refs and values through dozens of vi's, and every day something else breaks when various elements are reselected. I'm moving more and more things into globals and unnamed clusters, because these don't keep changing. The advantages of named clusters turn to dust if the clusters keep reselecting their elements. This is happening inside clusters I haven't touched in months, perhaps because they are clusters within my supercluster and I change other clusters inside that.

I've been considering trying to create an unnamed cluster where the first element is always an array of strings that identify the remaining elements, and trying to think through how to automate the disassembly of this cluster on the receiving end. It sure would be great if named clusters were robust - it's hard to predict how much more trouble and how many more delays my project will see.

Sorry, but - what is a CAR? Is there a name for this bug? How do I look for news about it?

Thanks!

---

A CAR is a Corrective Action report.

Names really don't mean much.

I have been able to work-around this bug by editing the type defs with all VI that use it closed.

Just trying to help,

Ben

[cebailey]

Ben, thanks, nice to talk to you again. Jdoyle above seems to say that editing the clusters with the vis that use it closed will just postpone their breaking until you use them. Do I understand right, and is it so in your experience? How is that better?

[Ben]

---

cebailey wrote:
Ben, thanks, nice to talk to you again. Jdoyle above seems to say that editing the clusters with the vis that use it closed will just postpone their breaking until you use them. Do I understand right, and is it so in your experience? How is that better?

---

Thank you for jogging my memory.

First I am not minimizing this bug (since I think I logged the first report of these bugs going back to LV 7).

In the LV 7 version of this bug it was better to keep the VI open.

In the LV 8 version of this bug I did batle in the Champions forum over this bug and at first NI had difficulty recreating it because they were doing the edit with the VIs closed and that was the suggested work-around.

This is the part I forgot to mention...

The bug comes up when a cluster element is renamed or deleted. I believe the "rename" part does not show up if the edit is done with the callers closed (just trusting my old memory on that point). The deleting part need another approach.

Option 1: Do not delete elements.

OPtion 2: With all VIs open, change the representation of the element you are going to delete to an incompartable data type (change numerics to strings). When you do that, all of the locations where the element that will be deleted will break in the code. Go through and delete all refs to that element by chacing down the broken run arrows. After all instances are deleted, then close everything and save it. THen open the type def and remove the element.

I sure I hope I am remembering that correctly, but I can count on Y'all to tell me when I am wrong.

Have fun!

Ben 

[Roy_F]

The bundle problem is documented in Known Issues, http://zone.ni.com/devzone/cda/tut/p/id/7324#117209_by_category. The workaround documented there says:

Change the data type (numeric to string, string to numeric) of the cluster element to be deleted to force breakage at all references to that member. Repair the broken VIs and then remove the cluster element. Or you can delete the cluster element, save (keeping the control open), then mass compile (or whatever ensures all users of the typedef are resaved while the control is open). 

Essentially, what Ben already told you, just done in a few less words.

Roy