Deleting Control from Type Definition casuses many misreferences and program errors in Block Diagram

[dbaechtel]

In LabVIEW 2010, I have a Type Def'd Control that is a Cluster with several other controls inside the Cluster. Apparently the references to the Controls in the Block Diagram are based upon the order that the Controls were added to the Type Definition Control. The side effect of this is that, if a Control is deleted from the Type Definition Control, many of the Variable references in the Block Diagram or now either broken, or even worse, refer to the wrong control in the Type Definition. These problems are fairly hard to find and fix.

From my observations: If you create a Type Definition Control and make it a Cluster. Now add any Controls to the Cluster in an order, let's say A,B,C,D. Their types do not matter. Now use the Type Definition in one or more Front Panel Controls. In the Block Diagram make references to the Controls inside the Type Def'd Control on the FP. Now go back to the Type Definition and delete Control B from the Type Definition. Now many errors appear. Broken links. But worse you see old references to B that are now referencing C, and old references to C are now referring to D, and old references to D are deleted altogether, etc.  This side effect causes alot more errors, broken links and misreferences than would otherwise be expected.

How can I add and delete Controls anywhere in a Cluster in a Type Definition, at will, without creating a whole bunch of program errors, broken links and misreferences to the Controls in the Type Definition that were not changed?

[RavensFan]

How do you mean that you are making "references to the controls inside the typedef control"?  Are you using the unbundle cluster function?  If so, you should be using the unbundle by name function.

If this isn't what you mean, please post some code or a screenshot so we can see what it is you mean.

[dbaechtel]

---

@Ravens Fan wrote:

How do you mean that you are making "references to the controls inside the typedef control"?  Are you using the unbundle cluster function?  If so, you should be using the unbundle by name function.

If this isn't what you mean, please post some code or a screenshot so we can see what it is you mean.

---

Most of the reference in the Block Diagram were Variable Property Nodes. Like Property A value, B strings[], C text.text, etc.

It was not Unbundle By Name. Unbundle by Name may or may not work after the edit to the Type Def. Probably would, I haven't tried it.

But using Unbundle by Name everywhere instead of the Variable Property Node would be alot more tedious work.

I hope that I don't have to resort to that just because the references used by the Variable Property Nodes was poorly implemented and is (very) sensitive to insertion and deletion order of Controls inside of a Type Definition.

[RavensFan]

I think I understand better now.

At first I thought if you were unbundle cluster (the unnamed kind) then change the typedef will break things since the unbundle is based on position in cluster and nothing else.  Unbundle by name usually doesn't break things because the name of the element is used.  Though if you do enough of the wrong kind of changes, you can break an Unbundle by Name.

I didn't understand from your description that you were using property nodes, which of course can get you access to a lot more than just the values in the control.  That said, I don't think I've ever needed to use property nodes to get to other information in a typedef'd control.  So I don't know if what you are experiencing is normal and expected, or abnormal or possibly a bug.  I'd have to try to replicate it.  Perhaps others will know more.

If you can post a small example of a VI using the property nodes, and the .ctl file of your typedef'd control, it would go along way towards helping us figure out if the behavior is the same on our machines and versions of LV, or something about your particular machine/installation.

[dbaechtel]

Here's a quick summary of how to reproduce my results:

• Create a Type Definition Control.
• Start with a Cluster Control in the Type Definition. (I don't know if this contributes, but that's what I have.)
• Now add other Controls inside the Cluster: Text Controls, ComboBoxes, Enum Controls, ListBoxes (a little of everything). Make sure you have at least 4 Controls in the Cluster.
• Now on the Front Panel create some controls that use the Type Definition: On on the FP directly, another in a Tab Control, another in an Array of Controls.
• Now in your Block Diagram, use Variable Property Nodes to get at various properties of the Controls on the FP: use value, visibility, strings[], text.text, TopRow, etc.
• Debug to make sure that Block Diagram appears to be working properly.
• Now go back into the Type Definition and delete the 2nd Control that was added to the Cluster, Save and Update the FP Controls to the new TD.
• Notice in the Block Diagram that many things are broken that have no relation to the Control that was deleted.
• Notice that many of the Variable Property Nodes in the BD have been changed to refer to another Control in the TD that is next in the order in which it was added to the TD !!! May produce errors, may not !!!
• Now because of a simple Edit to the TD, you have alot of fixing and debugging to do.

[RavensFan]

I see what you mean.  (by the way, it is just property node,  not "variable property node")

If you delete a control in the cluster, any property node referencing it changes to a the next control in the cluster.

Basically, any property node that implicity references the control is really doing it by the order number in the cluster as opposed to an exact control reference.  Adding a control, or reordering the controls changes things as well.

If you have a property node referencing a control at the end of the cluster, and you delete a control, then the property node disappears, just like if you deleted a normal non-clustered control off the front panel.

I don't know if I would call this a bug.  Someone from NI can comment.  But I would say it certainly is an unexpected consequence of using property nodes to access specific controls in a cluster.

I tried an experiment figuring that a property node where you explicitly wire a reference to it would prevent the problem.  But I found that changing the cluster also changed the control that the reference was referring to.  Oddly, when the blockdiagram updated, the size of the reference did not change, although the label and text did.  Here I had a reference to and Enum, but it changed to the much longer "Waveform chart" without changing the bounds of the reference node after I deleted the first cluster item.  Seeing this behavior, gets me leaning a bit more towards calling it a bug.

 

[dbaechtel]

Thanks for your assistance.

I think that my Customers that observe machine misbehaver because I missed one or more of the changes to references in a Property Node that did not trigger an error message, would end up calling this a Bug.

One way I can think of that this could be fixed is: if the Controls within a Cluster were referenced to by a unique ID or GUID, not by the order in which they were added to the Cluster. This would make the references insensitive to any changes or edits to the Cluster. It would fix this side effect and prevent many of the errors and misreferences that occur when a "simple" edit to a TD is made. I am not commenting about how difficult that this might be to implement but it would be invisible to existing LabVIEW programs (of course unless someone has programmed with this side effect in mind).

[dbaechtel]

IMHO:

This issue can cause very BAD unintended consequences that can be difficult to find.

In my application it could cause property damage, injury, or even death.

IT NEEDS FIXED !

[JackDunaway]

You may consider classes in the future, since LabVIEW natively maintains mutation history of data structures as a language feature of LVOOP. (Also, it's typical to Mark As Solution the person who gave the information rather than yourself).

[dbaechtel]

---

@JackDunaway wrote:

You may consider classes in the future, since LabVIEW natively maintains mutation history of data structures as a language feature of LVOOP. (Also, it's typical to Mark As Solution the person who gave the information rather than yourself).

---

I usually mark as a Solution those statements that appear to be a Solution to the questions and issues that I posed in the original post, even if I have provided the statement of the Solution or a proposed Solution.

I will not mark as a Solution statements that just provide additional information or proof, but do not attempt to answer or provide a workaround for the original questions asked.

I very much appreciate the work and investigation that was done to verify the issue. That is why I gave Kudos. But it didn't seem to attempt to provide any solution or answer to the original questions.