LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to get the refnum (i.e. in hex) of a reentrant VI for calling it by reference

Solved!
Go to solution
Hi Partha,
   I'm sorry, I already installed LV 8.2 and cannot save VIs to previous versions except for LV 8.0.
   Can anybody else do it for Partha?
 
Thanks and regards,
   Guillermo
Message 11 of 14
(958 Views)

Well I'd like to resurrect this thread.  Isn't this really a bug, as Ton says?  Two different reentrant VI clones  should not be considered the same object, so why does the Equal? comparison claim that they are?  If you have two refnums to a cloned VI there is no test for equality except checking the clone name, which is weak, or at least makes this seem like a bug.

 

The Original poster's LVquestion2 JPG does not seem like a bug, because the bottom VI reference is closed, so the comparison against a valid reference will fail (depending on the execution order of the diagram).

0 Kudos
Message 12 of 14
(778 Views)

jdunham wrote:

Well I'd like to resurrect this thread.  Isn't this really a bug, as Ton says?  Two different reentrant VI clones  should not be considered the same object, so why does the Equal? comparison claim that they are?  If you have two refnums to a cloned VI there is no test for equality except checking the clone name, which is weak, or at least makes this seem like a bug.

 

The Original poster's LVquestion2 JPG does not seem like a bug, because the bottom VI reference is closed, so the comparison against a valid reference will fail (depending on the execution order of the diagram).


According to the documentation it is not a bug but intended behaviour. That this behaviour is not what you would want is another story. Since there is no other way to see if a refnum references the same object type but by comparing the typecasted refnum integers you can also compare for different instances I would suggest that this behaviour is actually desired.

 

With two simple comparisons you can now do a test for both same object type and same instance. If the comparison for refnums would be changed you had no way to test for same object type.

 

Rolf Kalbermatter

Rolf Kalbermatter
My Blog
Message 13 of 14
(761 Views)

rolfk wrote:

According to the documentation it is not a bug but intended behaviour. That this behaviour is not what you would want is another story. Since there is no other way to see if a refnum references the same object type but by comparing the typecasted refnum integers you can also compare for different instances I would suggest that this behaviour is actually desired.

 

With two simple comparisons you can now do a test for both same object type and same instance. If the comparison for refnums would be changed you had no way to test for same object type.

 


The only documentation I saw (the LabVIEW Help for "Equals?") said that the refnums are equal if they point to the same object.  I would take that to mean instance of an object since that's what refnums are all about.  It could be same type of object (which is what it evaluates) but the documentation is not specific enough.  If it really is about type and not instance, then NI should call it something else besides a 'refnum'.
 Of course queue refnums work totally differently.  Different references to the exact same queue are not equal, and there's nothing about checking queues for compatible types.
If you need to check VI type you can compare VI name, and if you need to coompare instance you can check clone name, but the whole API is kind of lacking here.
 For example, the Clone Name property throws an error if you pass a non-reentrant VI, so if you just want a unique string for any VI reference there's no single property node to return that.  (but I digress!)
 Jason 

 

0 Kudos
Message 14 of 14
(737 Views)