LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Kirk

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

Status: New

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.

13 Comments
wiebe@CARYA
Knight of NI

Just gave a kudo. After 20 years of LV I learned to not do things like this. I don't have type def clusters anymore anyway (they're replaced with classes). But...

 

1) The different behavior between a cluster change and a type def cluster change is weird to me. One could 'practice' with a cluster to check behavior, to find their application ruined when applying the change to the type def. And undo won't fix it.

 

2) Replacing the item with the next item seems random to me.

AristosQueue (NI)
NI Employee (retired)

It might not fix things in a specific case. In fact, it pretty much by definition must do the wrong thing in some scenarios. The suggestion was that LV should not fix things at all based on names. Maybe there should be a tweak somewhere to make wrong cases rarer, but if LV does any fixup, then there will always be cases that it gets wrong. I think the cases that it gets wrong are worth the cases that it gets right.

Zafer.Depe
Active Participant

@ wrote:

It might not fix things in a specific case. In fact, it pretty much by definition must do the wrong thing in some scenarios. The suggestion was that LV should not fix things at all based on names. Maybe there should be a tweak somewhere to make wrong cases rarer, but if LV does any fixup, then there will always be cases that it gets wrong. I think the cases that it gets wrong are worth the cases that it gets right.


This problem is really annoying. When I add/remove input(s) or rearrange inputs of "Register for Events node" LV changes Event Cases irrationally. Please leave cases as they are, break the code and let us rearrange cases manually. Please do not try to fix anything. Just show us which cases are broken.