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

[Ben]

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

ditto that!

Ben

[tst]

"And no one showed us to the land
And no one knows the wheres or whys
But something stirs and
Something tries
And starts to climb towards the light"

Ditto that as well. We all want to "climb towards the light".

BTW, John, here's a personal request - If they haven't changed it yet, please, for the love of god, get them to have the Write\Read Spreadsheet File handle strings as part of their polymorphism. I never understood why there are instructions for how to change it instead of having the original itself do that.

[Johnner]

tst,

Sadly, Write/Read Spreadsheet still don't support strings natively. It is pretty mystifying. I will submit a Product Feedback request, as should you and others, so that the "market" can help decide the issue.

For you, I will also submit a beta suggestion/bug report, though that may not be an effective channel. It may be that this improvement was already considered in the LabVIEW team's create new feature/improve old feature calculus, and my understanding is that the relative volume of the various Product Feedback requests is a big part of that calculus...

--John

[Steven_H.]

Here's what's happening:

References from the Controls[] property are non-strict; references from the CtlRef terminal of an event structure are strict. Hence, they have different values for the same control. (In short, a strict reference is "strict" in that it encompasses not only the control's class, e.g. slide, knob, etc., but also its datatype, e.g. I32, DBL, etc.)

The Equal? primitive in LabVIEW 7.1 is not smart enough to equate a strict and a non-strict reference from the same control and return TRUE. This is the behavior you're seeing. We'll make Equal? smarter in a future version of LabVIEW

In the meantime, you can use the attached "Compare References" VI to compare these references. It will return TRUE if the reference refers to the same control, regardless of strict-ness.

Steven H.

[m3nth]

Bravo! The "why" is answered!

Excellent information... thanks also for posting the VI.

[Johnner]

Yes, good work, Steven! You've even managed to bring things full-circle by supplying a tool that nfol (the original poster here, who may well be tired of "thread activity" e-mails by now) can use to do exactly what he wants.

Since I was making sure to cast my non-strict references to strict versions before doing my test compares, the explanation doesn't quite explain everything for me, but I'm content to let it end anyway.

Regards,
John

[Foni]

Hi, and thanks for answers and the vi. Good to know why it didn't work. And I'm not a he,but she.
Nina

[chilly_charly]

---

nfol wrote:...And I'm not a he,but she.
Nina

---

Did you ever met a thing named tst ?

[Steven_H.]

To address John's most recent point:

Upcasting removes the strictness of the reference, but does not change its value. That is why the Equals? function still returns FALSE.

Steven H.

[tst]

I'm glad we got an answer.
I'm surprised to see I'm the only one who gave Nina 5 stars. I think her original post definitely deserves this, if only for bringing this issue to mind.
Steven, I shall refrain from asking more questions about this, but I do have a couple of requests\remarks:
Since the original problem originated from using a Search 1D Array (I'm assuming), I'm assuming the comparison routines in LV are inherent to all these functions and that your line about changing this is relevant to all of them.
Please, get the Read\Write Spreadsheet to handle strings.
Thank you.

Charly, no words.