See the idea discussion thread for multiple ways to read the labels of cluster constant element labels.
Good day forum. Can't seem to find a method to extract cluster element label names from cluster constants. Maybe through a malleable subVI? Would prefer to have that together with the control reference method. Thanks
Pretty sure this has been proposed before, but I can't find it.
No need for a .vim, variants would do that. A .vim would only be useful to make an interface without coercion dots. Variants would still be required (for now and AFAIK the distant future).
Would prefer to have that together with the control reference method.
Yes, it might be nice although I'd rarely use it. If you need it is something that is missing.
How would it deal with recursion (clusters in clusters)?
What should the function return? A (recursive) cluster of strings or an array?
It would be relatively easy to make custom solutions for this. That would do it exactly what is required by the situation. But making a function that pleases all might not be that easy.
I'm not sure how scripting would be useful. When placing a cluster constant, it would be very inconvenient to attain a reference to it, just to get it's names.
I think OP is looking to do this:
Or this:
The variant method works, but a function will be faster. It might even be possible to do this at compile time?
Is this that performance critical? Those names could be cached on first call (I.e. make that subVI full reentrant and use the First Call? primitive so you only calculate the first time it is called). I don't think a new mechanism is warranted.
Is this that performance critical? Those names could be cached on first call (I.e. make that subVI full reentrant and use the First Call? primitive so you only calculate the first time it is called). I don't think a new mechanism is warranted.
I was going to mention the First Call reentrant construct where I posted the code. But as long as the VI accepts a variant, this would give the wrong information if an element out of array of different clusters converted to variants was used... It will work with constants though.
It's absolutely possible to do this "manually". A new mechanism is not needed.
One might even argue that if you need this, you're doing it wrong. Can't think of a good use case myself. Maybe OP can share one?
This might become more interesting with regard to type traits though... Compiler time resolution in a .vim of a cluster to it's elements (and labels) and some way to recourse over them? I do want .vim's to be fast. It's a stretch, I know...
As soon as we can get the labels of the elements, we can do it a level lower. And if we can do it, we can make the requested .vim our self.
Getting a label of an input in a .vim is not possible at the moment. It's preventing me to replace code where variants are used. Since the names\labels of the connected .vim input wires are known at compile time, changing the labels of the .vim to the wired input labels would be really convenient. But that's another idea. It would allow the .vim to read the labels of what's wired, but we would still need to convert to variant to get that label. If\when .vim's evolve, there might become a need to get labels more easily.
Good day forum. Many thanks for all the comments and valuable feedback.
Reason why I proposed the cluster element name extraction is because I was using a configuration file read and write into a recursive cluster with arrays and cluster in it. you may think of my recursive cluster as something similar to the IMAQ ROI arrayed recursive cluster. I use the constant cluster label extraction to perform a match and set cluster function during initialization.
I shall look more into the some of the suggestions posted here.
@AristoQueue: how do you create the cluster constant refnum, is it just a reference and how to link that FP control to a BD constant?
@wiebe@CARYA: yes, that is somewhat my intended application. so, I guess I have to make my own subvi for this 🙂
See the idea discussion thread for multiple ways to read the labels of cluster constant element labels.