What is the expected behaviour when searching an array of re-entrant VI references?

[NRiver]

Hi,

I'm wondering if someone could clear up something for me. I'm working on some code that can dynamically register and unregister VI events for asynchronously launched VIs. To keep track of the VIs that are running I have been storing VI references in arrays. When an event from a VI fires, the event case returns the VI's reference and I have been looking in the arrays to determine which VI fired the event.

When searching the array of VI references, the search function always returns index 0. All the VIs launched are all clones of the same VI, so it seems like the search is not occurring on the reference itself, but on something that is linked to the source vi.

To work around this I have been casting the references to integers and the search 1d array function works as I would expect, so there is no major issue but I'd like to understand what is going on behind the scenes. I have found this post from a long time ago referring to the same behaviour but it's not clear to me from this if it's a bug or expected behaviour (if it's a bug then perhaps it still is, or if it is expected behaviour then re-entrant VIs are a corner case where different behaviour is desirable?):

https://forums.ni.com/t5/LabVIEW/Search-1D-Array-behaves-strange-when-operating-on-an-array-of-VI/m-... 

Attached is an example to show the behaviour (LV2023). 5 Async VIs are launched and their VI references retrieved. Indexing through the array of references returns 0. 

Whatever is going on is also affecting maps as I've seen similar behaviour in maps when the VI reference is the key. 

Naeem

[rolfk · Accepted solution]

It's the standard problem of equality testing. If you have different references referring the same object, should it be equal or not. LabVIEW in the beginning used to do a pure refnum value testing. It is what you would like (mostly) but it is often not very useful. There still is a difficulty about if you compare the object instead of the refnum. For reentrant instances you can have two more equal values: if the actual class is equal or if the specific instance is equal. LabVIEW still seems to choose for the first, which IMHO is usually not the best choice.

Note that testing for refnum value equality is in fact not the same than testing for object instance equality. A refnum can be different but still refer to the same object instance. For most applications the refnum equality is however good enough since you can't easily generate multiple refnums to the same VI instance.

[NRiver]

Hi Rolf,

Thanks for the reply - that all makes sense

Naeem