As I was vainly trying to make sense of my recent mistaken Idea Exchang submission (here), I stumbled upon a behavior I am not sure I understand.
Here it goes:
Drop an array of numerics on the FP. Show a few elements. The easiest is to grab an "Array - Numeric (Silver)" preformed object, with 3 elements shown.
Now, right-click on the top element and select: Create>>Property Node>>Value
Change that to write on the BD and connect a constant to it, say 1. Run the VI, you get this:
So far so good.
Now do the same for the THIRD element and wire a different constant to the PN, say 3. Run the VI again, you get this:
I mean, it already doesn't make much sense, but wait for what's coming...
Now, delete the first PN and rerun the VI:
Perfectly logical, right? ... not!
At least *I* can't make sense of it and this smells like a bug to me... or a weird feature.
Tested in LV 2013 SP1 (62+2 bits) on Windows 7 64 bits.
Solved! Go to Solution.
You are creating a shortcut to write to the ArrElem.Value property. The ArrayElement property of an array is a bit funky, it is the last element which has been active. With only a single PN on your BD writing a value, click in the middle element of the array and then run the VI, repeat for other elements.
In the second picture, you didn't enforce the data flow, so the 3rd item in the array (the active one) got set to 3, and then set to 1.
If you enforce the data flow, it looks different.
You will get 3 instead of 1, if you wire like this:
As Darrin said, it just matters which element is considered the "active" element. So in your second example, you actually wrote to it a 3 and then a 1 (classic race condition). You can set the active element with a property of the array (having trouble finding it at the moment).
Makes more sense now (@Zou: I had actually noticed what you illustrate, but I had not try to figure out the reason yet).
This being said, how do I know which element is active programmatically?
The bounds I can get are those of the Array, even if I pull that from a reference to an element.
The only way I can figure to get the Mouse Click location and indeed compute the array element based on some arithmetic.
Put a listbox behind it.
Make sure the row height same.
use the listbox invoke node: point to row, to get the active array index in the mouse down event.
@zou: that's a workaround.
My point is that we get this nice Last Active Element Value PN (Read and Write) but we essentially are left to guess (or work out) which it is. That's fine, but it would seem natural to have some helpers there, such as an "Index of Last Active Element" PN, for instance.
I actually meant to suggest the ArrayElement.Position property. I am pretty certain that one works for the individual elements (I kind of assumed the bounds would as well). Not that I have undertaken this in a long, long time.