LabVIEW
Programmatically choose boolean to write in cluster
Solved!
Short version:
I want to write and read the status of a boolean in a cluster by name, but i want to choose which boolean programmatically.
Long version:
I've been searching and trying for many hours but i feel i'm missing something obvious and i'm stuck in a loop. No pun intended.
The reason behind this is that i can program one loop that adapts itself to a source. Meaning, when i press 1 button, lets say "button A", the loop knows what to do for everything in the program with the name A.
I've tried many things like working with property nodes and variants etc.. while writing this question, i figured the property nodes out, sorta. I wonder if there is an easier way.
Many thanks in advance to anyone who can solve my issue.
I know i can always get rid of the cluster and do things easier (yet bulkier), but i have to know if and of so, how it is possible.
(You are leaving out a lot of details, but I cannot open LabVIEW 2024. Consider "save for previous, 2020 or below before sharing)
A cluster is a datatype that cannot change at runtime, so getting the label text with every iteration is silly. That belongs before the loop!
Does the cluster only contain booleans or can there also be other element types? If this is just a collection of boolean, I would maintain it as a 1D array in a shift register. No need for local variables. Conversion to cluster only needs to be done for display.
Overall, this seems all rather silly. Can you explain the overall purpose of this jumping through all these flaming hoops?
I am sure there are significantly better ways to do whatever you need to do, just take a step back first instead of digging an even deeper hole.
@NIquist wrote:
I might be misunderstanding your needs, but just use a case structure?
Yes this is the easiest to understand solution and i was considering taking the step back to a simple case structure. But this meant making a single case for all 20+ boolean. My plan was to extract the name of the button that was pushed, and use this to adres the appropriate boolean.
This way i would only need 1 loop for all 20 situations.
@altenbach wrote:
(You are leaving out a lot of details, but I cannot open LabVIEW 2024. Consider "save for previous, 2020 or below before sharing)
A cluster is a datatype that cannot change at runtime, so getting the label text with every iteration is silly. That belongs before the loop!
Does the cluster only contain booleans or can there also be other element types? If this is just a collection of boolean, I would maintain it as a 1D array in a shift register. No need for local variables. Conversion to cluster only needs to be done for display.
Overall, this seems all rather silly. Can you explain the overall purpose of this jumping through all these flaming hoops?
I am sure there are significantly better ways to do whatever you need to do, just take a step back first instead of digging an even deeper hole.
I like this option and this is probably what i was searching for.
I got the idea from some of my previous work:
The idea was that there would be one dynamic loop, which adapts to a choice made by the user, instead of a case structure with many cases.
For instance:
• Button with label C has been pressed:
→ loop trough all boolean
→ Set boolean 1 and 2 TRUE
→ boolean C found set status of boolean C TRUE
• Button B pressed:
→ loop trough all boolean,
→ Set boolean 1 and 2 TRUE
→ boolean B found, set status of boolean B TRUE
It seemed so obvious to me that labview would have a function inside clusters, where i could just easily select the boolean as you can with context menu:
So that's why i asked.
What if there would also be other elements than booleans? Would this still work?
This all still looks extremely convoluted. Please attach code instead of pictures. Don't forget to "save for previous".
Why have two sequential for loops if one could do the job? Why the local variables? Why the convoluted Boolean logic? Why call it radiobuttons. (That terminology typically means that only one can be true at any given time and it is not obvious if that applies here.)
@SydneyAVDE wrote:
If you're referring to the radio button example, I think I did that because otherwise, the label of the previously active button would be read instead of the newly activated one. Then again, I could probably just use NewVal. I'll confirm this tomorrow.
That statement makes no sense! You are operating on the same reference in both loops.
I don't understand the exact requirements, but to act on properties of the changed element (that triggered the event), here's a code skeleton that you probably could adapt to your requirements. (I am sure changes are needed, I am only shown the general logic)
As said before, I am sure once you attach some simplified code of the problem, we could give more targeted advice.
