Get name of cluster element as a string

[altenbach]

Lets go back to the core of the original question:

---

@CatDoe wrote:

I do not want to manually write headers for all my elements as the names and orders may change when the physical program is edited in the future by other people who will not know the program or update these details. I do not need to output the entire cluster.

---

You have not really explained the detailed use case, so please do when you get a chance. My gut feeling is that you are looking for a "solution" in all the wrong places. You talk about "headers". Are these e.g. column headers for tables/spreadsheet files, etc.

The names of controls, indicators, cluster elements, etc. can only be changed at edit time. Same for cluster types. Overloading element names to carry vital processing data is just asking for problems down the line. I would recommend a much more scalable solution where the name of the data is carried elsewhere in a central place (ini file, map, string diagram constant etc.) so it can easily be changed, e.g. if the UI should be offered in various languages. 

The names of cluster elements are ignored for processing and are thus fully determined by the last processing step that touched it, e.g. the output indicator connector of the last subVI).

[raphschru]

Hi CatDoe,

This will give you the element names of any cluster:

    

 

[drjdpowell]

---

@rolfk wrote:

 and they definitely look more obvious to me as to what is going on in the code.

---

The Variant-based solution that raphschru just gave seems equally clear to the Property Node one altenbach gave.  

[drjdpowell]

---

@altenbach wrote:

You have not really explained the detailed use case, so please do when you get a chance. My gut feeling is that you are looking for a "solution" in all the wrong places. .

---

I don't know OP's use case, but I find I often use this kind of technique.  I think OP is trying to avoid naming the same thing in multiple places, requiring code to be changed in multiple places when names change. This is the price rolfk was "willing to pay" in solving his sparse enum issue. 

[raphschru]

The variant-based solution, besides being 30-40 times faster than the property-node-based solution, is also reusable in a subVI as it operates on a generic variant cluster.

Here is my benchmark comparing the 2 solutions:

[CatDoe]

Yes, I am striving to avoid editing in multiple places. My main VI is very complicated and clusters may be updated without realizing headers need to be updated as well.

These headers cannot be contained in a .ini file as if they are updated, the cluster should be as well. This program will be edited in the development stage and redistributed if this cluster needs to be updated. A .ini file cannot provide the editing capabilities necessary for the edit this cluster may require in the future.