Deleting a control from a typedef Cluster

[GerdW]

Hi 1984,

With a cluster its easy, but if everything is separated I need to create a subVI which receives these 15 different controls and do the math inside.

To repeat: nobody said you should use 150+ separate controls!

All I said was: separate your typedef datatype from your UI handling…

In your Ctrl1.ValueChange event you write the new value to your (typedef) cluster and call your subVI. The subVI returns a flag/value for Ctrl1 in case you have to deny/change user input…

[crossrulz]

The more I'm thinking about this, the more I'm convinced you do not want the cluster on the Front Panel, certainly not the type def.  You can keep a copy of the type def in the shift register, just like I recommended before.  And you can still access all of your front panel items via the property node if you really need to.

[Poema]

What's the function description of a   'typedef'   cluster if your program gets messed up after you removing or adding controls (even if you change the tab order of the controls) wherever you use it? It's a real bug.

[crossrulz]

---

@Poema wrote:

What's the function description of a   'typedef'   cluster if your program gets messed up after you removing or adding controls (even if you change the tab order of the controls) wherever you use it? It's a real bug.

---

If you use Unbundle By Name and Bundle By Name, the only places you should get errors when changing the cluster type def is where you called out the items that were deleted.  The normal Unbundle and Bundle do not have this convenience.

[billko]

---

@Poema wrote:

What's the function description of a   'typedef'   cluster if your program gets messed up after you removing or adding controls (even if you change the tab order of the controls) wherever you use it? It's a real bug.

---

This isn't a bug - it's the typdef's greatest asset!  It breaks your code where you have to change things around so you don't have to guess where things need to be updated.  Or did I misunderstand what you actually meant?

[Poema]

Normally the strength of a typedef (cluster) is that you can use on a lot of places in your program and when the typedef changes it updates all those places. In labview anything can be messed up after a change.

In other languages, if you change a typedef structure by adding or removing or even change the sequence within the structure all existing references are ok. (only the change has effect)

The problem in labview is that the controls in a cluster are saved as an array of references to controls and as we all know when we add or remove an element (a control in this case) in an array the whole array changes. (by the way the order of the controls in the cluster is the same as the tab order)

In labview the property of a control in referencing to the index of the control array within the cluster, so that's why in labview the program your is messed up if you change the controls within the cluster and also the typedefs based on that cluster.

The bug is here that a property should by connected to the reference of the control and not the index of the control reference array within the cluster.

I hope you can understand my explanation.

[1984]

Great explanation! 

(I learnt that I have a minority opinion about this subject, but I still consider this a quite major bug in labview.)

[billko]

---

@Poema wrote:

Normally the strength of a typedef (cluster) is that you can use on a lot of places in your program and when the typedef changes it updates all those places. In labview anything can be messed up after a change.

In other languages, if you change a typedef structure by adding or removing or even change the sequence within the structure all existing references are ok. (only the change has effect)

The problem in labview is that the controls in a cluster are saved as an array of references to controls and as we all know when we add or remove an element (a control in this case) in an array the whole array changes. (by the way the order of the controls in the cluster is the same as the tab order)

In labview the property of a control in referencing to the index of the control array within the cluster, so that's why in labview the program your is messed up if you change the controls within the cluster and also the typedefs based on that cluster.

The bug is here that a property should by connected to the reference of the control and not the index of the control reference array within the cluster.

I hope you can understand my explanation.

---

I see what the focus of your explanation is, and this part I agree with.  I've always thought that referencing controls within a cluster was the most fragile part of any code that I wrote.  In an attempt to at least somewhat mitigate this, I've iterated over the array of references to find the control name property so at least if the order changed, it wouldn't affect the code adversely.  (If someone has a better way to do this, I'd be happy to hear about it.)   This also makes it really tedious to use a cluster in an event case.

So I did miss the point.  "Messed up" didn't mean "broken arrow" - it meant "messed up" like it DIDN'T cause a broken arrow, even though the code isn't going to function as intended.  That is truly "messed up".

[Poema]

 If you change the order within the cluster your program is messed up, property's are switched, events in your event case switched, ...  in other words your program is messed up

[Kevin_Price]

To borrow a quote, "LabVIEW didn't do this to you.  YOU did this to you."

Now let me explain.  At some point you chose to base your code around knowing the relationship between the indices of an array of control refs and the actual cluster elements at those indices.

Then, at some later point, you changed the cluster definition thus destroying the relationship your code was based around.

So now you're at a point that's frustrating with code that's potentially dangerous.  That stinks, and I *do* sympathize with that feeling of having coded my way into a dead end.  But there really is no reasonable expectation that LabVIEW should be able to automatically fix this when you redefine the cluster.  How *could* it?  Do you expect it should go find all control ref indexing operations and then start changing numeric constants that define your indices?   I for one would strongly object to a behavior where constants I placed on a diagram were changed behind my back.

Here's the C analogy.  You have a typedef'ed struct full of mixed datatypes.  You wrote your code to know the byte offset from the struct pointer to each individual data member of the struct.  Whenever you wanted to, say, manipulate the u8, you'd access it by adding 13 to the struct pointer to locate the known byte offset to the u8 field, and then operate on it that way.

And *then* you go and change the struct definition so the u8 is now at offset 16 and a float occupies the byte at offset 13.  Now let's consider the code where you mess around with whatever's at byte offset 13.  Is there a C compiler that will automatically fix this for you?  No, of course not. 

The problem was choosing to use a fragile method to access data in a structure, then breaking the basis for that fragile method by redefining the structure of the data.

So I disagree that this is a problem with LabVIEW.  You'd have the same problem in C if you chose to access your data via similarly indirect methods.

-Kevin P