05-04-2009 11:49 PM
Running LabView Full 8.6 (not 8.6.1) on Windows XP SP3
I have two buttons for which I created references to pass down to a sub-vi (to control
visibility of the buttons during initialization). On the sub-vi both Refnum controls are
strict ("Include data type" is checked). However, at the top-level, the two refnums for
the (seemingly) identical buttons are different. One refnum is strict and the other is not!
Of course this was a problem because it would not let me connect the refnum to the
sub-vi.
I tried various combinations of duplicating and re-linking the reference objects but it
always came up with one strict and the other not (always the same ones the same
way).
In the end, I found that the only difference between the two buttons other than
the label name and boolean text was that the mechanical actions were different:
- the button for which the reference was strict has "Latch when Pressed"
- the button with the non-strict reference has"Switch until Released"
Is there some underlying reason why the choice of mechanical action
should affect the "strictness" of a boolean control refnum?
Or is this just another "unanticipated feature"?
(Not a problem anymore since it was the wrong mechanical action
selected to begin with -- fixed that and fixed the problem. But it
looks like there might be something interesting to learn here.)
Thanks and Best Regards,
-- J.
Solved! Go to Solution.
05-05-2009 02:04 AM
When you have a latch mechanical action, you can't use the Value property to read the value of the control. Thus, its data type (which is what makes it strict) is not included with it. That's my educated guess.
In general, the right thing to do would probably be to right click the reference control and uncheck Include Data Type, which would make it non-strict. Additionally, you could have tried casting the reference to the class you want, but you should want this would only work if they were actually of the relevant class.
05-07-2009 08:57 PM
"When you have a latch mechanical action, you can't use the Value property to read the value of the control."
Now that you point that out it makes sense. See, that's why I posted the question 🙂
Thanks,
-- J.