02-22-2012 02:10 PM
Whenever I use the ctrl reference inside an event case I always do things like read the control's label text to determine which control was manipulated - that way the exact number becomes a nonissue.
Mike...
02-22-2012 03:54 PM
@mikeporter wrote:
Whenever I use the ctrl reference inside an event case I always do things like read the control's label text to determine which control was manipulated - that way the exact number becomes a nonissue.
Mike...
Mike,
I am not comparing the exact number, I do not care what the exact number is actually - I leave that for the equal function to resolve. I am comparing two refnums that should resolve to the same front panel control. According to the documentation, the 'equal' function should return true.
Recall smercurio_fc post:
The actual values of the references don't need to be the same. The references would be "equal" if they point to the same object.
In fact, the LabVIEW Help explicitly says "When comparing VI Server references, these functions return TRUE or FALSE based on whether the two references refer to the same object, regardless of whether the references have the same value or the same capability."
So, comparing labels this would be a work around to the bug. The point is that a feature that worked properly in LV2009 and 2010 no longer worked in 2011. True, if I used labels I would never have seen this bug, but I try to avoid String compares as they are not very efficient. Also, you can have two controls with the same label. There should never be two controls with the same refnum.
Kurt
02-24-2012 08:05 AM
I'm on your side Kurt.
I have used that construct in applicaitons and it used to work. It is a bug that should be fixed.
Ben
05-07-2012 11:28 AM
This issue is still present in LV 2011 SP1.
It also occurs if you're searching an array of references to type defs using the "Search 1D Array" function; the function returns -1. If it's an array of references to controls it returns the correct index.
08-22-2012 02:30 PM
FYI - The reference to CAR 323101 should actually be CAR 323332, which is fixed in LabVIEW 2012.
A related problem (discussed here) has also been CARed.
Roy