how get cluster element value change event

[crossrulz]

---

@GokulGKM wrote:

You can easily create a seperate event for each cluster element.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

i know this way. why i asking this mean i have lot of even structure so need to reduce the number of event structure in my program.

---

Event Structures or Event Cases?  A single Event Structure can have many Event Cases and you can have event cases handle multiple events.

[Ben]

"Divide and conquer"

... can be used if you create sub-VI for the various modes of operation. Put the config actions in a config VI that is passed control refs and dynamically registers event against the controls that are config related. All of the sub-VIs that run like that can all register their own events against a common stop button. I have delivered applications that use bunch of event structures but none of them in the main VI that houses the controls and indicators. My "LabVIEW Basics I and II" customers have been able to support the code with little help from me using this approach.

Just offering another way to reduce the number of envet structures in a VI.

Ben

[paul_cardinale]

As I said, this would only be for an app that has a lot of controls; and therefore needs to capture a lot of value change events.

Instead of having one event structure with a very long list of cases, they are nested.  The outer event structure capturing Value Change events for various clusters, and inner event structures to handle the value changes for individual cluster elements.  This makes it easier to navigate the code.

While you can create problems by nesting event structures, it is possible to do it correctly.

Rules such as "Always do X" and "Never do Y" should really be "It's usually best to do X", and "Beware of doing Y".

[useroflabview]

I really like this idea of nesting event structures. Even if it is not recommended. But it makes the event structure code much more readable.

[altenbach]

No, it does not!

[paul_cardinale]

That's your opinion.  Mine is different.

[RavensFan]

Nesting event structures is a very bad idea.  In theory you can do it and it could work, but it is just a small programming error away from having an ugly mess of code that will lock up tight when you execute something.

I would strongly discourage anyone from ever doing it.

Spoiler

Just because someone says something is their opinion doesn't make it a good idea or even a correct statement.

[paul_cardinale]

Just because it's easy to mess up something doesn't mean it should never be done.  And it isn't that hard to properly nest event structures; it only requires a little dilligance.

You said "In theory you can do it and it could work"; I do it, and in practice, it works fine.

As for programming errors that cause lockups, I don't find those so hard to debug.

In general, I don't believe in adhering to programming practices that are designed for the specific purpose of hamstringing inept programmers in a vain effort to get decent code out of them.

[RavensFan]

Just because you can do something and it can work, doesn't mean you should do that.

And you certainly shouldn't suggest something that can easily be messed up to someone who doesn't even know the basics of how to use an event structure yet.  That is a complete disservice to them, anyone who has to use their code, and anyone who has to clean up their code after them once it breaks.

[paul_cardinale]

You wrote "Just because you can do something and it can work, doesn't mean you should do that.".  I agree with that, and never implied to the contrary.

However I disagree about your admonition to never offer challenging approaches to beginners (especially in this case where it's not particularly challenging).

I find your assertion of absolutes somewhat entertaining.  Things like "you certainly shouldn't suggest", and "That is a complete disservice".

Thank you for your advice; but I'll ignore it.

Hamstrings will never protect us from bad programmers.