LabVIEW
Updating cluster values, is there a better way?
Mark Yedinak wrote:
B O B wrote:I believe the issue lies with the cluster size setting on the array to cluster function:
Right-click and select cluster size, then set this to 15 for your VI. Let us know if this works!
-Bob
Preferred architecture aside, 17 is actually the correct size here, you will notice that he is using Replace Array Element and not autoindexing an array. Hopefully he fixed the bug I pointed out since he should be using a SR with this method. Not really necessary if he follows my example.
The cluster order is not what he expects, but that shouldn't cause an error (I don't think). In fact the only way I could get the same error was by setting the cluster size to 15. With only a screenshot and not the code, it is just guesswork (my guess is that the cluster size is not what he thinks it is).
For the record, I agree in principle with the TypeDef argument, almost always a good idea for clusters. However, adding complexity because you are having trouble with the simple case is usually a recipe for trouble. Myself, I tend to stick to good old-fashioned arrays and if I need to I index with a text ring or enum instead of bundle/unbundle by name.
Darin.K wrote:
Mark Yedinak wrote:
B O B wrote:I believe the issue lies with the cluster size setting on the array to cluster function:
Right-click and select cluster size, then set this to 15 for your VI. Let us know if this works!
-Bob
Preferred architecture aside, 17 is actually the correct size here, you will notice that he is using Replace Array Element and not autoindexing an array. Hopefully he fixed the bug I pointed out since he should be using a SR with this method. Not really necessary if he follows my example.
The cluster order is not what he expects, but that shouldn't cause an error (I don't think). In fact the only way I could get the same error was by setting the cluster size to 15. With only a screenshot and not the code, it is just guesswork (my guess is that the cluster size is not what he thinks it is).
For the record, I agree in principle with the TypeDef argument, almost always a good idea for clusters. However, adding complexity because you are having trouble with the simple case is usually a recipe for trouble. Myself, I tend to stick to good old-fashioned arrays and if I need to I index with a text ring or enum instead of bundle/unbundle by name.
I agree that keeping things simple has its advantages. However, too simple can be a problem too. Since he was trying to bundle a set of items that all have a specific meaning and context, the cluster is a better approach since it is self documenting. An array of references to log files can be difficult to keep track of. Which log file was at which index? What happens when I need to add or delete log files? Do I need to go through all of the code and find my magic numbers for the indices to specific log files? If he wants to always use an array then I would at least define an ENUM that helped to track which array element was which thing.
Of course this could also be handled using an action action or an array of clusters. Overall I don't believe the suggestion I posted is overly complicated and it does help make the code more readable (when accessing specific elements at other points in the code) and maintainable.
Mark Yedinak wrote:Myself, I tend to stick to good old-fashioned arrays and if I need to I index with a text ring or enum instead of bundle/unbundle by name.
If he wants to always use an array then I would at least define an ENUM that helped to track which array element was which thing.
I believe we are in furious agreement.
I do like your suggestion, and while not overly complex, is certainly more complex than a simple flatten/unflatten, which turns out to be more complex than the simple Type Cast I imagined. I just wanted to make sure that we sorted out the simple case before moving on up. I am here to fix his problem today, your here to keep him from having problems like this in the first place. 
Get the Control[] property of the cluster and you can easily loop through all fields, especially as you have a nice array of paths to start out with (which can be built from 2 simple nested loops, one 1-5 and one with the 3 names).
/Y
