Deleting a control from a typedef Cluster

[GerdW]

Hi 1984,

Its like if I would delete an element from an array and as a result the rest of the elements would get scrambled.

Yes, they get scrambled - when you insist on using constant element indices! (Those references seem to work like "reference of n-th element of your typedef cluster"…)

Why do you need all those references on elements of your typedef?

[1984]

Because if I have a massive cluster on the UI, its hell lot easier and less space consuming to get the value of a given element by a property node than to read it with unbundling the cluster.

Plus there are tons of cases when I dont just need to read or write. I may need to start blinking something, use a value (signaling) property, change the background color of an element etc etc

[GerdW]

Hi 1984,

its hell lot easier and less space consuming to get the value of a given element by a property node than to read it with unbundling the cluster.

Great misconception…

I may need to start blinking something, use a value (signaling) property, change the background color of an element etc etc

So you have a typedef that is made to create a DATATYPE description - but you start to fiddle with UI look?

Then separate your typedef from your UI…

[Intaris]

OK, reading Gerd's answers it seems I totally misunderstood what is going on here.

Static references to cluster contents?  Heck no, don't do that.  If you MUST get references to the individual items, put the logic in a sub-VI and use the sub-VI with a cluster input to get the individual references back.. This way you have ONE location to fix.

Now that I understood the magnitude of the problem I have to say this behaviour is NOT a bug, it's bad programming.  It's so far from what I would consider doing I didn't see the treed for the forest 

Or as Gerd says, decouple your data structure from your UI altogether.

[1984]

"Great misconception…"

No its not. It is actually easier and less space consuming. Although I see you are a person who is alway right, right?

[1984]

Ok... it could be bad programming. (Not sure if that changes anything, but the original post is purely about the property nodes and not about references. I know references are a different animal).

So if its bad programming what should do with about 150 different controls. So far I have used a cluster, which bundled them into one nice structure, now I will have 150 separate controls. With a cluster when I had to do anything with its elements I just created a subVI with the typedef'ed cluster input and did it inside.

So in other words how should I handle 100+ controls without completely messing up my block diagram?

thx,

[GerdW]

Hi 1984,

Although I see you are a person who is alway right, right?

No, ofcourse not.

But as long as you only describe what you are doing and as long as I read "bad programming behaviour" I will say so…

how should I handle 100+ controls without completely messing up my block diagram?

Usually you use an event structure to handle UI events!

This will end in a while loop and an event structure with a lot of cases…

So far I have used a cluster, which bundled them into one nice structure, now I will have 150 separate controls.

Nobody said you have to use 150 separate controls. You can use clusters or arrays - but you should not tie them to your typedef cluster when you want to change that typedef repeatedly…

[1984]

I use event structures extensively. The problem I forcast for myself is that while so far I had everything inside of an entity I could read an event of lets say a "value change" of a given control, then drive the entire cluster drive into a subVI and do math / operations inside. Now as my controls are separated, I somehow have to drive them individually into the subVIs. And as each subVI does different things in each case of the event stucture I have to deal with the individual controls. This is a LOT less unified solution as each VI need to have different inputs and also a lot less scalable as if I add a new control I may need to change lots of subVIs.

example: user changes the value of ctrl1 and to validate his changes I want to check the contents of 15 other controls, numerics - booleans - strings - enums mixed. 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.

I understand the approach that a typdefed cluster is a datatype and not really a UI element. But using it as the part of the UI has so much benefit over using separated controls that I must think that the issue I have described at the beginning of this topic is really an issue with labview. 

[crossrulz]

---

@1984 wrote:

"Great misconception…"

No its not. It is actually easier and less space consuming. Although I see you are a person who is alway right, right?

---

But HORRIBLY EXPENSIVE.  Property Nodes are absolutely the slowest way to get a value from a control/indicators.  You would be much better off keeping a copy of the cluster in a shift register so that you can unbundle/bundle the elements you need to.

[1984]

I am not arguing that part... (although in my app that slowness is acceptable)

The problem I try describing is that I dont need the values only. I made the cluster as the part of my UI which has lots of benefits. And by simply using a shift reg. I can't access properties except but the values, while I need a lot more.