Interactions with clusters inside a cluster

[1984]

Hi,

For the example sake let say I have a cluster including ButtonA, a string control and ButtonB. If the user presses ButtonA it disables/enables the string control and ButtonB. If the user presses buttonB then it enables/disables ButtonA. I can capture the button presses in an event structure and set the disabled property of the other two elements accordingly. This is easy.

On my UI I need several of these clusters though, so I was thinking about grouping them. It can no be an array cause once I disable something in one array element it get disabled everywhere. So I guess I need to put my clusters into another cluster. From this point the event handling gets really difficult especially if there are more elements in the smaller clusters and if there are more possible interactions. How to solve this problem in the less painful manner?

I know this question has popped up couple times on the forums and I think the advice was to not allow the user to edit the encapsulating cluster, just a smaller one and use a listbox to select which smaller cluster you really want to edit. (one of the posts: https://forums.ni.com/t5/LabVIEW/Enable-Disable-Array-cluster-elements/td-p/3915693)

I think cripples the UI quite a bit, cause is an absolutely legit expectation from the customer to see everything at once and be able to edit each one of the clusters without selecting something in a listbox.

So maybe the answer remains the same, but I think its worth seeing if there are any - relatively painless - alternatives to solve this challenge.

Thanks.

[raphschru]

I would need a clearer definition of your actual problem to give a better response, but here are some general advices:

To easily enable/disable multiple controls at once, I would put them in a cluster and enable/disable the cluster instead. Some cluster styles such as the "Classic" style can even be fully transparent with no borders if you do not want to visually burden your UI.

You can programmatically get control references and register their events dynamically if you want to handle several cluster instances with the same behaviors without duplicating the code.

Another way is to create a standalone control such as an XControl (native NI tech, can be tricky to debug) or a QControl (more convenient, available from VIPM). In this way, you completely separate the UI logic of your cluster(s) in separate event structure(s) instead of polluting your main event structure.

Regards,

Raphaël.

[drjdpowell]

What you can do is:

• Get a reference to the outer cluster
• Use a Property Node to get an array of references to all contained clusters 
• For each contained cluster, get references to the A, B and string controls (casting them to their correct type of Boolean or text)
• Make arrays of each (A buttons, etc.)
• Register events on those arrays of references 
• When an event fires, find the control reference from the event in the array of references. This tells you the index of the cluster the user interacted with. 
• Use that index to get the other controls in that cluster 

For example, a Button A value change event happens and the event's ctl ref is the third element of the array of Buttons A, so you get the third element of the array of Buttons B and disabled it. 

[Yamaeda · Accepted solution]

Maybe something like this?

[1984]

---

@Yamaeda wrote:

Maybe something like this?

---

 Yeap, could be like this its a bit annoying that if you have many clusters then you need to register to many "buttonA" events, but this at least keeps all buttonA actions at one visible place.

[Yamaeda]

---

@1984 wrote:

---

@Yamaeda wrote:

Maybe something like this?

---

 Yeap, could be like this its a bit annoying that if you have many clusters then you need to register to many "buttonA" events, but this at least keeps all buttonA actions at one visible place.

---

Yeah, the event list will be kind of long, but all of the same type handled in one place should be pretty clean.

[1984]

---

@Yamaeda wrote:

Maybe something like this?

---

There must be more than one valid solutions to this problem, but I have already implemented yours which for my case was surprisingly painless. Nice little victory for a Friday afternoon. Thanks!

[Bob_Schor]

I have several Projects that have "Cluster Wires" of different types (needless-to-say doing different things) and have never considered "lumping them" into a "super-Cluster".  I don't group the clusters at all, but keep the different "Cluster wires" distinct.  I might have a top-level VI that has, say, 3 or 4 Cluster Wires running across a "State Machine Loop" (a While Loop that unbundles the State and arguments and an inner Case structure that processes the selected State, with an Error Handler sub-VI to process State errors).

A "trick" I learned from a colleague at work was to make the Clusters a Class, not so much for "class"-ical reasons but to make the "Class" wire uniquely "decorated" so it didn't look like an "ordinary" Cluster wire.  This is similar to what NI did with the Error Line -- it's "just a Cluster", but it has a unique/distinctive look on the Block Diagram so it is instantly recognized as something "special".

Bob Schor

Hmm -- that will teach me to do the grocery shopping in the middle of posting a response to the LabVIEW Forum -- by the time I get back, several other posts have "snuck in" before I finished mine, and a "Solution" has been reached.

Well, I still prefer creating "distinctive Clusters" that each have a unique Definition and Properties (including the wire appearance to make them distinctive on the Block Diagram).  But to each, his (or her) own ...

Bob Schor

[1984]

---

@Bob_Schor wrote:

"Solution" has been reached.

Constructive thoughts are always welcome, even if the problem is solved (in one way).

Based on your comment, its still not clear for me how your way of programming would solve the problem in the original post. What if you need 10 clusters to watch?

The idea of keeping the clusters separated has been mentioned in the forums several times, but I have not seen an actual implentation. Could you post a simple template-like VI?

[Bob_Schor]

I think that I have to agree with your comment (= "how does my suggestion solve the original problem") -- I went back to your original query and tried to figure out what you were trying to do, and I just didn't "get it".  Without out understanding the "What are you trying to do" question, the discussion of "How can you implement this behavior" seems premature.

But now that I realize this, a suggestion (from my own experience) comes to mind.  I once helped a colleague design a VI to monitor the behavior of up to 24 mice, in 24 separate "test station" (cages) over an interval of 150 minutes.  Each Station had a video camera to record 5 to 15 second videos of behavior, and a Boolean "Event Detector" that was polled (I forget at what frequency, maybe 10-30 Hz?).

The Front Panel (partially shown below) had a "Status" indicator consisting of 24 Boolean Controls that served several purposes.  When setting up a study, mouse "subjects" were placed in a pre-determined "Station" numbered "S 01" through "S 24" (the numbering order corresponds to the position of the racks of cages being used).  At the beginning of the study, all Status indicators were "Off" (as shown below) -- the Experimenter would put a (known) Mouse in a pre-determined Station, then push the Station button to show the Station was "active" and "Ready to go ("= Green"), When all the mice were in place, the "Start" button initiated Data Collection.

Now the Station buttons served a different purpose.  If a lit "Green" button was pushed, its video feed appeared

in the sub-panel below (here labeled "Station 22").  If any Station's Event Detector fired, the (already lit) Status light changed color (I don't remember to what), going back to Green when the Event ended (typically 3-10 seconds).  Note that if another Station fired off an Event, that Event was still registered and its Camera feed stored on disk, but the Video display didn't change until the Operator manually switched the Station being monitored (at least, I think that was the logic I used).  

If an Error was detected for the code running on any active Station, the Station code was aborted and the Station Status set to Black.  If the Station ran without error for 150 minutes, it turned itself off (I don't recall if we coded that with a Status color of Black or some other color, say Red).  Once all the Stations turned themselves off (either because of Error or "Ran OK for 150 minutes, or whatever Session time was set), the program wrapped itself up and exited.

This was my first major routine that used Channel Wires to implement a Channel Message Handler design pattern (think QMH with Messager Channel Wires -- a more sophisticated version of the Channel Message Handler can be found in the Examples that ship with LabVIEW since about LabVIEW 2020).

Bob Schor