LabVIEW should not internally track cluster controls with an index but rather with a name.

[Kirk]

If I have an existing cluster in my project and one day I decide to delete one of the elements of that cluster, LabVIEW tries to fix all the references or black them out to help me find the errors.  However, It seems that LabVIEW in some instances keeps track of clusters internal controls with an index and when you delete something, those indexes are now messed up. 

For Example, if you have a property node linked directly to an item within that cluster, then you delete an item in that cluster, the property node now points to something else.  OOOPS! 

Also, if you have an Event Structure Case pointed to a control within this cluster, and one of the other controls in the cluster get's deleted, this Event structure case now points to the wrong thing!

LabVIEW is internally keeping track of the controls in a cluster with an index.  It works fine as long as you only add new stuff to the cluster.  But if you delete things, LabVIEW does not handle it well.

If LabVIEW instead had a notion of the name of the items, then it probably could recover well when an item was deleted from a cluster.

[fabric]

Auto-updating of bundles/unbundles/events/etc is one of the most frustrating behaviours of LabVIEW. 

In a perfect world the editor would magically know exactly what to do, but unfortunately there are fundamental ambiguities in determining how any given cluster modification should be handled.

Consider the case where I have a cluster with 3 elements {A,B,C}. Let's say I delete B, then add a new element D, then reorder to get {A,D,C}. What should happen? Did I intend that all references to B should now point to D, or should all references to B be broken? What if B and D have the same name? And/or the same type? There are countless such examples...

For this reason I would prefer that the editor NEVER tries to rewire anything for me. I'd much rather manually fix a bunch of broken wires than realise a month later that some unbundles got jumbled and I never noticed!

[wiebe@CARYA]

This is not cluster behavior, it's type def cluster behavior.

Of course lots of clusters are (and should) be type defs...

If you create a reference, an event or a property node to a cluster element, deleting the element will delete the property node, the reference, and the event structure will break.

If the cluster happens to be in a type def, the behavior is different. The property node, reference and event structure get update to the next element. As described.

So it's updating a type def cluster behavior that needs to change. Updating a type def cluster should behave as a updating normal cluster.

[Kirk]

I agree with Chris and Wiebe.   Probably the best thing to do is to break the event entries and property nodes, etc.  Not change them to the next entry.   The current method of changing it to the next control is not the way to go.

[Zafer.Depe]

I frequently use dynamically registered event structures that handle event refnums which are inside typedef clusters. When I add a new refnum to the (typedef) cluster, following events automatically switch next events.

 

 

I just copied "Stop Actor UI" event refnum inside the cluster and handled event window automatically swicthed.

 

[AristosQueue (NI)]

Speaking purely for myself as a G programmer and NOT as a member of LV R&D:

I think the current behavior is correct. Yes, it sometimes means LV fixes code the wrong way. But it also means LV often fixes code the right way and saves me a lot of time compared to other languages that I work in. The rules for fixup are deterministic, so when I edit my cluster, I know what pain I'm about to inflict on myself by editing a cluster, and I can plan accordingly.

There's a balance to strike between full burden on the programmer and the IDE doing too much. In this instance, I think the IDE has the right balance. But that's my personal opinion.

Speaking as a member of LV R&D: I don't know if the user base has ever been systemically studied on this issue. I certainly don't know of any attempt. I don't know where most users would land. We'd need to get a pretty good sample before messing with something that has been the same behavior for so long. But it might be worth doing.

And, PS: This is one of those things that should definitely NOT be a Tools>>Options setting. If user A revises a toolkit in a way that should not break callers but user B has turned off the option that keeps the callers from breaking, it really messes up user A's ability to make and distribute non-breaking changes. We need a consistent rule for how diagrams mutate in response to dependency changes. I don't mind if the rule changes, but it needs to be one rule to ring them all. 😉

[wiebe@CARYA]

AQ wrote: I think the current behavior is correct. Yes, it sometimes means LV fixes code the wrong way.

But why is this behavior different for a cluster, versus a type def' cluster?

If the type def cluster behavior is correct, why isn't this the behavior of a cluster?

Is this on purpose; reasoning that a cluster doesn't do much damage, so it breaks code, while a type def is potentially used all over the place, so it automatically 'fixes' things?

[Zafer.Depe]

wiebe@CARYA wrote:

...so it automatically 'fixes' things?

---

If I have two or more typedef event refnum clusters connected to and Event Handler Structure and when I add one or more event refnums to one of the typedef clusters then Event Handler Structure automatically switches handled event window refnum even it is not inside the changed typedef cluster how should we say that is a fix? 🤔

[wiebe@CARYA]

That's why I put the quotes around 'fixes'.

[Zafer.Depe]

I understood your sarcasm and replied to support your comment. Actually I ask AQ "how that should be fixing things" via your comment. Maybe it was not clear. Needed a thumb up after your comment 😉

---

wiebe@CARYA wrote:

...so it automatically 'fixes' things?

---

👍

[wiebe@CARYA]

OK. That's cleared up now.

This all reminds me of (type def) enums. In older versions, enum values would automatically get some other value (the next?) if the value got deleted. Things could be horribly wrong, and nobody would notice. I'd prefer an approach similar to enums. Greyed out if there's ambiguity, until explicitly updated by the user.