When you get a data changed event from an array, it would be nice if that event included an array of what items in the array actually changed. This makes it easier for the user to determine what changed and how to deal with it.
Many of my arrays are arrays of complicated clusters (containing, scalars, clusters, arrays, etc.), so how far should it drill down, for example if only a single innermost element has changed somewhere?
Could you clarify what "an array of what items in the array actually changed" actually means. It could be a boolean array of the same structure (= what you get if you do a "!=" (set to compare elements) of the new and old value), it could also be a simple I32 array containing the indices of changed elements.
As a first step, a simple array of toplevel indices migh be sufficient.
The boolean array structure is easily re-created by a simple comparison, so we probably don't need that.
The most generic for for this would be an array containing indices for what elements changed. For a multidimensional array, this would need to be either a cluster with number of elements equal to the number of dimensions or a 2D array with the second dimension equal to the number of array dimensions. This would only handle changes to any part of the top level item in an array, and I would be satisfied with that. Further adding support for which part of the cluster in the array in the cluster changed would certainly be useful, but not very often, and I am not sure the extra complexity it could generate in the simple case would be worth the added functionality.
An alternate would be an array of booleans with similar data structure to the original, but this is trivially generated with a simple equals node at the moment, and would still require cycling through it to find what changed.
You can easily get this information using the Equals primitive and then scanning for True values in the resulting array. The Event structure should most definitiely NOT provide this information since not all event handlers want to waste time doing the comparison.
I'm with Stephen on this one. It would be a nasty interface if it should be able to cover any data type, you're not always interested in this scan anyway, and it's easily achievable by using the Equals primitive.
It's a bit similar to when dealing with an array of events within a single event frame; it's usually pretty straightforward to verify which event triggered the case without the event structure supplying the index:
Of course the entire "array of events" functionality is broken in LabVIEW 2012 apparently without any fix coming out, so I can't use LV 2012 yet. Good we only ported a single workstation to 2012 before discovering this deadly bug.
I must disagree with my esteemed colleagues on this one. I have had to implement this solution often enough to be annoyed with it, hence the suggestion.
The compiler should be smart enough not to generate code if the output is not wired.
Using an Equals node and scanning for FALSE values is only a good solution if you have a small array. There are more memory and time efficient ways to do this. I would not expect a casual LabVIEW user to be aware of them, but that is what should be under the hood.
