This issue has bugged me for a long time . I just got bit again and I wonder if anyone else has a workaround.
I just checked and LV 2009 has it too.
Create a custom control of a cluster with three elements named A, B, C (numeric controls, booleans, whatever, it doesn't matter).
Make it a TYPE DEF (non-strict) and save it.
Put an instance of it on a new VI panel.
Create a PROPERTY NODE for item B and set it to DISABLED property.
Wire a constant to that property node.
Now, if you run the VI, it sets the DISABLED property of item B to the value of the constant. Fine.
Now go to the TYPEDEF, and add another item, called A2 to the cluster.
Re-arrange the cluster order so that it's A, A2, B, C, and save the type def.
Look at your diagram. The property node is no longer linked to B, it's now linked to A2.
Apparently, LV uses the cluster order internally to keep track of the links. So now I'm linked to A2, not B.
If A2 was a different type of object from B, then you MIGHT get lucky and the diagram breaks. At least then, you can see the fact that it changed.
But almost everything has a DISABLED and a VISIBLE property, if that's the one you're using, then you won't notice that it was changed behind your back.
I have taken to adding a free label with the name of the expected control (in parentheses) next to the property node, along with the true label. So if I see a discrepancy between the true label and the free label, I can recognize such a case.
But that's only if I remember that this crap happens.
Anybody got any better ideas? How can I prevent, or at least recognize, such an unwanted change?
Bonus question: the same thing happens with events, for the same reason (I suppose). If I tied an event to item B, that event switches to item A2 behind my back.
