Is it possible to programatically determine the index (order) of a particular element in a cluster constant (typedef)? The cluster is not a control cluster, so using the controls[] array is not an option.
It seems like this would be a property operation, but as there are no 'references' for non-control objects (are there?), there are no properties of non-control objects. I use non-control clusters a lot. I have struggled with the same issue when trying to retrieve cluster element names from non-control clusters (all roads lead to OpenG 🙂 don't want to install VIPM 😞 ).
I use a DVR of a cluster of arrays to share data across an app, and use in Place Element structures to read/write the the arrays. Each array (all BOOLs or DBLs) represents an array of values to write to output modules (digital and analog). Generally I only update the arrays in one loop, and read in multiple VIs/loops.
From the start, I stored the data as arrays, but later in development I created cluster typedefs for clarity when using the data around a FP VI (mostly when reading the data from the array and displaying on indicators).
The exception to the write-once/read-many rule is when I simply want to set or clear a single BOOL bit.
Attached is an illustration showing 2 ways to do the same thing.
The DVR Read/Write Element structure on the RIGHT illustrates how I currently update a single element of a BOOL array. In particular, I want to set bit-2 of an array named 'bOutputCmds'. bOutputCmds[] is an element of a cluster named 'IoCluster', and the 'IoCluster' is shared throughout the app by a DVR named 'IoDataRef'. Safely updating the value of the bit requires 3 In Place operation (In Place DVR R/W, In Place UnBundle, and In Place Array Index).
This works fine. However, proper operation requires specifying the index of the bit of interest, in this case, '2'. I could assign constants for all the particular bits, but it would seem more appropriate to take advantage of the typedefs I have created. The typedefs allow me to make changes to the IO assignments and describe the configuration in only one place. The DVR R/W Element on the LEFT illustrates a way to update a single bit (safely) by cluster element name.
Extracting the index of element 'bLoadEna' (2) from the cluster typedef used on the LEFT would make the solution on the RIGHT much cleaner.
My backup is to replace all the arrays I originally put in the shared cluster with the individual clusters that later I so carefully defined, or, replace all non-control clusters with Indicator clusters. Either will work fine. Mostly I am technically curious as I tend to be bumping up against the limitations of non-control clusters quite often. I seem to be a non-UI programmer in a UI world.
Actually, my last statement was rhetorical, but is really quite true. My application is a headless embedded controller, so I do not need or use many controls. Maybe I should think about that some before picking on non-control clusters...
Done.
Thanks,
Peter
