Comparison of references failed

[gerh]

Hello,

recently I've observed a strange behavior when trying to compare two references referring to the same typedefed controls.

What I want achieve:

I've created a typedefed control (a cluster of radio buttons with additional informations) for use on the UI front end. To manipulate the contents I've created a subVI which takes a reference of the front end control. The functionality is not of interest - it controls the values represented by the radio buttons, so the whole thing is some kind of "advanced radio button control".

Now I need to address the data structure of the cluster components. The first approach was to compare the labels with a hard-coded string. But then I discarded this first attempt because if somebody changes the labels of the front end control the subVI won't work anymore without a visible reason. So I decided to compare references.

So far the introducing story...

Now I observed some kind of pathologic behavior - and that's my question:

Attached to this post is a small demonstration VI which should make clear what is the issue about.
First I've created an instance of the control. For simplicity let's call it "MyControl".
Then I created two references to this object.

The first one by selecting the "VI Server Reference" from the "Application Control" menu. Done that, a right click on the reference and choosing the menu item "Link to .../Pane/MyControl" creates the link to the control. If I open the same menu entry then there are no check-marks in the menu (this becomes important later).

The second I've created by a right click onto MyControl and selecting the menu item "Create/Reference". As difference to the first this reference shows checkmarks in the "Link to ..." entry of the right-click-menu.

Both references seem to be linked properly to the control if used to read or write any properties. But if I try to compare them using the "Equal?" or "Not Equal?" functions of the "Comparison" palette the result is inequality. Unless the type-casted numbers or the references by itself are compared.

I know the value of the references may differ in value, but the comparison functions should handle that by resolving the references before the equality check. (see the documentation of the comparison palette)

Why are the references unequal? Also a right click onto the control or it's terminal and selecting "Find all references" from the right-click-menu finds only the first of both references.

Is it an issue of referencing the typedef and the structure the typedef contains? (only typedefed controls behave like described, after disconnection from typedef the comparison works)

One more thing I found out: selecting "Link to .../Pane/MyControl" from the right-click-menu of the second reference (the check-marked entry) links the reference properly, even for the comparison functions and the "Find all references" function. Done this, the check-marks vanish.

How can I ensure proper linked references? Is there a better - more stable - way to refer to a control than by label or a reference?
Is it a bug? I'm using LabView 2011 (without SP1) on a win7 notebook.

[Vijay_J]

I downloaded the VI and run in LabVIEW 2011 and LabVIEW 2013 SP1 Environments.

Please find the screen shot attachments.

Your observations are right in terms of behavior in executing the code in LabVIEW 2011. Control references return two different ref num (reference number), which explains the behavior.

In LabVIEW 2013 SP1, control references return the same reference number.

You might need to upgrade, if it is the LabVIEW Run time engine or Compiler behavior.

[P@Anand]

As said I got the same result in 2013 that the references are equal. Is this know issue (248914) relates your work?

[crossrulz]

---

@gerh wrote:

Both references seem to be linked properly to the control if used to read or write any properties. But if I try to compare them using the "Equal?" or "Not Equal?" functions of the "Comparison" palette the result is inequality. Unless the type-casted numbers or the references by itself are compared.

---

I am 99% sure that the Equal and Not Equal compare the reference number.  Yes, they may be pointing to the same thing, but the reference number is different.

[P@Anand]

---

@crossrulz wrote:

---

@gerh wrote:

Both references seem to be linked properly to the control if used to read or write any properties. But if I try to compare them using the "Equal?" or "Not Equal?" functions of the "Comparison" palette the result is inequality. Unless the type-casted numbers or the references by itself are compared.

---

I am 99% sure that the Equal and Not Equal compare the reference number.  Yes, they may be pointing to the same thing, but the reference number is different.

---

Sorry I don't understand. Do you mean a control can have 2 different reference numbers? (I don't think so)

[crossrulz]

---

P@Anand wrote:

Sorry I don't understand. Do you mean a control can have 2 different reference numbers? (I don't think so)

---

Just look at the Type Cast to U32.  That is the actual reference number.  For me, 2011 SP1 had different numbers; 2013 SP1 had the same number.  So it looks like NI fixed it either with 2013 SP1 or with a patch since.

[P@Anand]

---

@crossrulz wrote:

---

P@Anand wrote:

Sorry I don't understand. Do you mean a control can have 2 different reference numbers? (I don't think so)

---

Just look at the Type Cast to U32.  That is the actual reference number.  For me, 2011 SP1 had different numbers; 2013 SP1 had the same number.  So it looks like NI fixed it either with 2013 SP1 or with a patch since.

---

Yes even I have checked it. I was just curious to know how a reference is created for a control downstream.

[crossrulz]

---

P@Anand wrote:

Yes even I have checked it. I was just curious to know how a reference is created for a control downstream.

---

I've done it with VI Server starting with a reference of the VI to get a reference of the pane, and then get a reference to all of the controls on the pane.  But it looks like these have been fixed as well (I used to get a different refnum going this route).

[P@Anand]

---

@crossrulz wrote:

---

P@Anand wrote:

Yes even I have checked it. I was just curious to know how a reference is created for a control downstream.

---

I've done it with VI Server starting with a reference of the VI to get a reference of the pane, and then get a reference to all of the controls on the pane.  But it looks like these have been fixed as well (I used to get a different refnum going this route).

---

Yes. In 2009 also it gives two different reference number, so it must be a recent fix.

[JÞB]

Comparing References.

References are equal if they refer to the same object.  This is true and has been a backbone philosophy of VI Server.  While it may change...I would not ever expect it to do so.  Even if one is strict and the other is non-strict if they refer to the same object they are equal.  Even if one is authenticated and the other is not if they refer to the same object they are equal.  The ONLY way to get two references to the same object to be un equal is to have one be a remote reference and the other to be a local reference (e.g. Automation refnums)  Or if there is a real problem with LabVIEW 

That being said lets put to bed CAR 248914  It has nothing to do with the OPs observations.

On the other hand CAR 367436 from the previous linked White paper was resolved for 2012 SP1

The work around has already been alluded to.  Create your references from the terminal and avoid the strange cast that occurs when "Relinking" a "Dropped VI Server" (Default, "this vi"class, VI VI) to a control ref of a type def 2011 - 2012 pre SP1