LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

combobox in array--why does it work this way?

POSSIBLE BUG!? Could this be two I've found in 1 week?!  If so, at this rate NI is going to want to stop me from using LabVIEW. I'm exposing its flaws.

0 Kudos
Message 11 of 20
(999 Views)

Looks like a bug to me... that's pretty odd behavior.  Same thing even without writing an empty array to the Value property node.

0 Kudos
Message 12 of 20
(994 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 13 of 20
(992 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 14 of 20
(987 Views)

Well, since I got it working, for now I'll leave it be until an app engineer comes and takes a look at it. If any of you guys want to mess around with it some more and you figure anything out, let me know.

0 Kudos
Message 15 of 20
(983 Views)

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. Smiley Wink

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 16 of 20
(977 Views)

@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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 17 of 20
(965 Views)

@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.Smiley Surprised Smiley Sad

 

 

Spoiler
I used that technique to turn a graph into a control whereby a user could easily compose temperature ramping profiles using cursors to define the critical points along the profile.

 

 

 

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. Smiley Wink

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 18 of 20
(953 Views)

Ben wrote:

 

So be careful what you call a bug, it may get fixed. Smiley Wink

 

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 Smiley Tongue.

 

 

Message 19 of 20
(940 Views)

@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. Smiley Wink

 

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.


--Using LV8.2, 8.6, 2009, 2012--
Message 20 of 20
(926 Views)