Reference to control different from reference panel->controls[]

[Ben]

OK,

I agree this is unexpected!

This is one of those times when we need what I requested in this thread.

http://forums.ni.com/ni/board/message?board.id=130&message.id=296&jump=true

Would anyone like to step forward and win themselves a nomination to the Knight of NI ranks?

Ben

[tst]

Actually, I'm sure you've noticed that on occasion there are some answers coming directly from R&D (and more often indirectly), most notably from sir Brian Tyler.
I understand you've seen this on 7.1, right?
Does anyone have access to 8.0 beta?

[Ben]

Yes the same in 7.1.

I will see if I can get an answer to this riddle.

Ben

[Johnner]

I see what you guys are talking about under LabVIEW 7.1. For what it's worth, the behavior is different with the LabVIEW beta, tst. At least for the VI I built along the lines of what you described, you get the exact same bits in the two references regardless whether they came from the root of the front panel or from a tab control.

My guess is that this has to do with whether or not LabVIEW creates a copy of reference under the hood or just reuses the same object (a sort of global in-placeness, I suppose). It seems as if LabVIEW could avoid making a copy, since I can't think of a way a user has to modify the value of a reference.

Philosophically, my inclination is to suggest that nobody should construct a VI that expects the actual bits of two reference objects to be identical, even though I see the potential benefit in nfol's case (though comparing label names instead isn't that rough). Is there documentation that suggests it is kosher to expect all references to the same object to comprise an identical set of bits? I'm trying to think of a good analogy involving pointers, but I'm coming up a little bit short.

My two cents, anyway,
John

[Johnner]

tst, drop me a line if you want to become a LabVIEW beta tester (e-mail address in my profile). I don't know for sure what the enrollment status is at this point, but I know the right guy to sweet-talk.

[tst]

I don't have LV in front of me at the moment, but if I remember correctly, the help item for Controls[] says that it returns an array of references for all the FP controls and indicators. It is my understanding (and it sounds logical too) that every control would only have a single reference. I guess NI has also found this to be logical, since you say this was fixed (thanks for that, BTW). Since there has to be something which uniquely identifies an object, why not have it constant, especially if it is for some cases (like the tab)?

Thanks for the beta suggestion. There is actually a page on this site where you can apply to be a beta tester.
I wonder, what do you do with a beta copy? Do you trust it enough to develop real code in it? If not, what do you do with it? Are there any benefits to being a beta tester other than learning about upcoming features in advance and being able to feel as a contributor?
The reason I'm asking is that it seems to me that in order to really test a beta, you would have to write (and test) enough code in it to find all the bugs. Or is this not so? I don't know any beta testers, so I would really like to hear about this.
Maybe we should open a thread in the breakpoint about this topic (not disclosing, of course, any secret NI stuff).

[Johnner]

tst,

Maybe the real question is why an Equal? node doesn't do something smarter than comparing the pointer values (or whatever it's currently doing) when you feed it a pair of refnums. It seems like it should be able to indicate whether or not the items being referenced are one and the same.

Beta testing: no, there's no great benefit to most testers, I'd say. Some developers probably use the opportunity to get a jump on migrating existing apps to the new version in order to take advantage of new features, but most testers are just in it to get a sneak peek and help make the release version of the product more robust. You could open a topic, but, as you surmise, discussion of specific features would be off-limits.

Individual beta users certainly don't have to test the product exhaustively in order to make a solid contribution...would that it were possible to find "all" the bugs!

--John

[tst]

In any case, I'm sure each object has a unique identifier. I just thought that would be the reference that LV exposes to the user. From this I understand that's it not the reference. I don't know how the internal representation of a control's ref works, but I wouldn't necessarily expect it to automatically detect that it is a control reference.
In any event (not a pun), we're all expecting the same thing - regardless of the internal implementation, LV should be able to compare 2 references to the same control.

I'm still left with the beta question unanswered - so what exactly do you do with it? If you can't use it for work, you have to find some off-work things to write in it. My understanding of your answer is that most testers just don't use too much, right?
Can you tell us the restrictions (in broad lines) for using the beta?

[Ben]

Jim Kring (of OpenG and one of NI's LabVIEW Champions)

http://www.openg.org/content/category/4/67/45/

suggested a possilbe explanation.

We often leave the application reference to default to the local LV.

If we open a reference to LV on another machine, the connection is subject to different conditions (ie is the network up?).

References that that can go away when the network goes down must be handled differently than those that are local.

I thought this was a good theory. It is better than anything I cam up with on my own.

Now as far as Beta testing.

If you read the agreement you will see that there is not much you can do or expect out of the beta version. You do have access to a special discusion group on this web-site that lets beta testers share their experiences.

NI has recognized some of the beta testers as MVP's for their work in the past. I think Albert Givens (another LabVIEW Champion) was ack'd for his work on LV 6.X.

A big benefit of the beta program is that you can make sure the bug you have in the current version is fixed in the next version.

Based on my observations of your and CC's abilities to to serach ou those seldom visited corners, you two would probably make great beta testers. Unfortunately once in as a beta tester you would not be allowed to tell us what you found!


Ben

[m3nth]

I was able to duplicate the original problem, however not just by creating 2 property nodes to get the Panel>Controls[] property as stated in the 6 step outline earlier by tst. Two duplicate parallel Controls[] gave me two identical control ref arrays. Comparing them against the control ref returned by an event structure however proved the original problem.

This post is highly reminiscent of problems I had a long time ago with a memory leak from using the Controls[] property. Find articles and posts here:

http://digital.ni.com/public.nsf/allkb/33C39B4F6B5EF20C86256F54007E47A9

http://digital.ni.com/public.nsf/allkb/8F3E5092F30EC65186256A18006F9F52

http://forums.ni.com/ni/board/message?board.id=170&message.id=31632&requireLogin=False

http://forums.ni.com/ni/board/message?board.id=170&message.id=30167&requireLogin=False


So my guess at why the FP.Controls[] property returns different references that aren't static is because it's making a copy ("instantiating"?) a new set of references each time it's called. That's also why you have to close those references or wind up with a memory leak if you're operating inside a loop--LabVIEW's making copies every time. Obviously however you don't have to do that for static references... they'll still exist even if you use them and then try and close the reference. That's also why you don't normally have to close references to avoid performance problems (well, that and the fact that references are small and even with multiple ref arrays take awhile to accumulate a significant amount of memory when the loop that they're being generated in is run at relatively slow speeds)

Whatever fix has been made to this in future LabVIEW versions is probably to do away with making copies of the references which gives new reference values, and instead returning the static values. That's probably the difference (currently) between the internal function that returns control references on a tab and the internal function that returns control references for the front panel. If indeed that is fixed for future versions, then it will also likely mean that you can leave the references 'open' in future versions without having to close them, since they are not newly generated and are instead the static control references.

I wouldn't mind hearing more on this from people who actually know what they're talking about 🙂