Possible bug with search 1D array of refnum

[Dan Press]

Title should read "array OF refnum"...

This is a crosspost.

This one just bit me so I thought I should share. It looks like the Search 1D Array function behaves unexpectedly when used with an array of VI refnums. So far I have only reproduced it in LabVIEW 2009 SP1, but I ran some code in 8.6.1 that seemed to have the same symptoms.

When I run the code above, I always get a zero for the output "index of element". In the example shown I expect to get 3. In fact if you change that 3 on the array index to any number, you get zero on the output. My workaround is to typecast the refnum array to an array of I32 and also typecast the refnum that I'm searching for. That makes it work, but I'm still freaked out by the odd behavior.

Note that the VI you throw the snippet into must be reentrant. I believe the search is getting confused because the refnums all point to the same VI, albeit different instances of that VI. Of course, that is the whole point of using the search 1D array function. I am trying to identify a particular instance.

Can anyone repeat this one?

Thanks,

Dan

[Grampa_of_Oliva_n_Eden]

Title should read "array OF refnum"...

This is a crosspost.

This one just bit me so I thought I should share. It looks like the Search 1D Array function behaves unexpectedly when used with an array of VI refnums. So far I have only reproduced it in LabVIEW 2009 SP1, but I ran some code in 8.6.1 that seemed to have the same symptoms.

When I run the code above, I always get a zero for the output "index of element". In the example shown I expect to get 3. In fact if you change that 3 on the array index to any number, you get zero on the output. My workaround is to typecast the refnum array to an array of I32 and also typecast the refnum that I'm searching for. That makes it work, but I'm still freaked out by the odd behavior.

Note that the VI you throw the snippet into must be reentrant. I believe the search is getting confused because the refnums all point to the same VI, albeit different instances of that VI. Of course, that is the whole point of using the search 1D array function. I am trying to identify a particular instance.

Can anyone repeat this one?

Thanks,

Dan

I don't have anything above 8.2 where I am so I have to ask... Does it do the dame thing if you insert a seq frame in the wire after the For loop and before the Serach?

Mike Porter told me about an issue where he was checking all VI's in memory after loading them and they fialed to show up. A seq structure after the Open and before the "all VI in Memory" fixed the issue for him.

This could be similar.

Ben

[Francois Normandin]

Confirmed LV2009, no service pack.

In the meantime, you can get around this bug by using a typecast on your refnums.

EDIT: And reproduced in 8.2.

[Rolf Kalbermatter]

Confirmed LV2009, no service pack.

In the meantime, you can get around this bug by using a typecast on your refnums.

EDIT: And reproduced in 8.2.

Yes somewhere around 8.0 or 8.2 they changed the behavior for refnums pointing to the same object. Before that, equality of refnums was merely based on the refnum itself. After that equality of refnums is based on the object the refnum refers to. Since all refnums refer in fact to the same VI (eventhough its instance is in fact different because of the 0x8 option) all of those refnums are considered equal. One could argue that at least for reentrant VIs this should not be true.

[Neil Pate]

Bump, confirmed this LabVIEW "feature" is still around in LV2015.

This is quite strange behaviour if you are not expecting it. I came across this bug when dealing with clones, all my refnums are unique, but when I search it matches the first clone in the array rather than my actual refnum.

The workaround of casting still works fine.

[infinitenothing]

I'm guessing that's intended behavior since the two references are "equal" (see below). The problem is "when are two references equal". Different people might have different answers. It's too bad you can't "override" the equivalence operator with a functor replacing the "heart of the algorithm"