LabVIEW
combobox in array--why does it work this way?
First of all, the clearing of the array works. I've seen this by stepping through the code and the array does get cleared. Wait, I removed the second write to the Value from the first property node.
Where it gets weird is that the value is being written to the i+3 element inside of the FOR loop.
After a little more playing, the number of lines skipped is somehow related to the number of array elements being shown. If you shink the front panel array to 2 elements, it works as expected.
EDIT: Found that the FOR loop is actually writing to the second from the bottom element being shown. LabVIEW 2011. I'll try it in 2012.
OH NO!
You said bug.
Anytime a bug is found with a rarely used code construct the bug gets "fixed" by disallowing it. Specifically, disallow a value property node for an array ref wire. Well, it was interesting trivia while it lasted. 
Ben
@crossrulz wrote:
Just to illustrate Ben's point...
I think there is definitely a race possibility here. Nothing in LabVIEW guarantees for current and future versions that the Array Control is updated before the loop starts trying to reference the same control. I'm not sure I understand the other troubles though.
But I would consider accessing the value property of an array element to be at best a bogus operation. There are arguments to be made to say it should be the top-left most element that gets referenced, but architecturally that most likely brings all kinds of complexities into the underlaying code, with the object having to know attributes of it's enclosing parent, that it should not have to access at all.
@rolfk wrote:
@crossrulz wrote:
Just to illustrate Ben's point...
I think there is definitely a race possibility here. Nothing in LabVIEW guarantees for current and future versions that the Array Control is updated before the loop starts trying to reference the same control. I'm not sure I understand the other troubles though.
But I would consider accessing the value property of an array element to be at best a bogus operation. There are arguments to be made to say it should be the top-left most element that gets referenced, but architecturally that most likely brings all kinds of complexities into the underlaying code, with the object having to know attributes of it's enclosing parent, that it should not have to access at all.
Re: race
Yes, "Array" must be upadated first for this to work.
Re: Top Left
I never read anything that indicated what "should" happen. My statements were based on my observations. In that Nugget I BELIEVE I mentioned that to get it to work reliably (can we rely on it to keep working this way) predictably I first defered the FP (in the evnt it was visable) and set the array such that only a single element of the array was visable when the property node >>>Value was invoked. Aftwards I set the array size back to the original.
Re: architectually ... complexities
Which brings me back to my comment about calling it a bug. The definition of a bug in NI's book as understood by myself is;
A bug is anytime the LV environment or generated code fails to perform as documented.
What we are looking at in this thread is (aside from my Nugget) completely undocumented. Since it is not documented we can not off-hand call it a bug in the NI sense of a bug. But before I go further I would like to please call your attention to this thread where CC and I discussed another "undocumented feature" where in the pre-LV8 version of the graphs, it was possible to create a reference to the cursor legend. This allowed access to elements of the cursur that we could not otherwise get at and also let us develop our own cursor legend layouts if we desired.
Since this was undocumented, the developers that re-wrote the grpahs and charts did not preserve this functionality.
So...
Before we go running down the hall repeating Bug Bug Bug... we should give some thought to what we have now and if we want to put in jeopardy this "feature". The most simply solution for the NI developers when faced with this feature presented as a bug they have to "adrress" is to take the approach, This is undocumented, lets make it unsupported and disallow using a Value property node with a an array elelemnt ref. CAR closed move on.
So be careful what you call a bug, it may get fixed.
Ben
Ben wrote:
So be careful what you call a bug, it may get fixed.
Ben
I have a solution. If it's not documented it can't act differently than documented. Ergo, not a bug. So, just document the current functionality as "this is how it works" and no change is needed. This avoids the problem ben ran into with graphs before. Normally, if I had the option between fixing how something works, and writing documentation so that I don't have to fix it, I'd choose fixing the code. Documentation sucks. But since NI has technical writers, the documentation sounds like the best option to me 
.
@Ben wrote:
So...
Before we go running down the hall repeating Bug Bug Bug... we should give some thought to what we have now and if we want to put in jeopardy this "feature". The most simply solution for the NI developers when faced with this feature presented as a bug they have to "adrress" is to take the approach, This is undocumented, lets make it unsupported and disallow using a Value property node with a an array elelemnt ref. CAR closed move on.
So be careful what you call a bug, it may get fixed.
Ben
If NI is listening, *please* don't remove value property for ArrElem. We use it for loading test scripts from file, lots of things would break without it.
