clone reference equal

[pawhan11]

Hello,

I am playing with clones recently and there is sitiation that i didn't expect.

When I open reference to 2 clones why they are equal?

When I typecast to string ant then compare they are not exual...

[Sam_Sharp]

How are you specifying the VI, you're missing wires from your screenshot?

There are some weird things with doing comparisons on VI references and clones - the VI reference shows as equal but if you look at the clone name property and/or type-cast the reference to an integer you'll see that they are clearly different.

I think this is a weird behaviour but I have seen it before.

[pawhan11]

Screen is only proof of concept, the same path for both open reference is used.

I came to the same conclusion, typecasting to string/integer solved my problem.

[Hooovahh]

Yeah when it comes to other languages, similar problems can happen.  I think it was in JAVA that if you did a string compare you'd say is this string equal to this?  But you were actually given pointers, and the comparision was on if the type of the pointer was the same so it would return true regardless of the contents the pointer pointed to.  In this case you had to say is the contents of the pointer equal to the contents of the other.

Casting to a raw refnum works.  You can probably also look at the Clone Name which is a property of the VI reference, that should be unique and not equal too.

[M_Peeker]

Comparing two references returns equal if the target of the references are equal, although the references themselves are not. 

I found this out from this excellent thread:

http://forums.ni.com/t5/BreakPoint/LabVIEW-Minutiae-that-may-bite-you-someday/td-p/1122234/highlight...

[paul_cardinale]

If it's the same path, then both references are refering to the same VI, not 2 clones.

[Hooovahh]

---

@paul_cardinale wrote:

If it's the same path, then both references are refering to the same VI, not 2 clones.

---

What if the VI isn't saved yet?  The path will be Not a Path which could be equal to other unsaved VIs.  Usually not a problem but still.

[rolfk · Accepted solution]

Typecasting to an integer is not generally a solutions. LabVIEW refnums are funny beasts. They are references to a LabVIEW object. Explicitedly opened refnums are usually different even if they reference the exact some object. VI Refnums created with the Open VI Reference are explicitedly opened and should result in different refnums refering to the same object even if you don't use the flag to open the VI as a reentrant clone instance. So comparing the numeric value of a refnum is not a safe way of determining if you have clones, they will be also different if you opened the VI twice without clone flag.

[rolfk]

---

@paul_cardinale wrote:

If it's the same path, then both references are refering to the same VI, not 2 clones.

---

Actually that is not quite true. Clones are in fact two instances of the same VI loaded into memory but maintaining their own indpendent data space. So the path is really the same for clones. What differs is the VI name which gets the extra number appended to distinguish several clones from each other.

Open VI Reference will normally create a new refnum pointing to the same VI that is already in memory but the open flag 0x8 modifies this to create a new dataspace for the resulting VI to use and in doing so does really the equivalent of creating clones. One thing to watch out though, this flag only works if the target VI is configured in its VI Options to be reentrant.

[pawhan11]

Shouldn't reference be like pointer to memory where vi is allocated?

In this case they clearly don't point into the same memory so they shouldn't be equal. This gives opposite results in case with controls of the same type.