05-07-2014 09:07 AM
Hullo,
I'm trying to figure out a reasonably supportable method for detecting whether a sub VI's input is wired.
I'm using the approach of setting a nonsensical default value for the control, then comparing the control's current value to a constant of this value. If they're not equal, then I pass the control's value into my shift register. If they are equal, I retain whatever value was previously in the shift register. In this instance, I've created an action engine that allows me to update status and progress bars.
This works because my progress counter is a U8 which I will only ever write 0-100 to, so I can set my default to something outside this range (here, 255) for my comparison. Something similar should be relatively simple to understand and reuse in the future.
However, there's a dependency on someone setting the default value for the control and then updating the comparison constant to match. My question: is there a method for checking the default value of a control programmatically in order to remove the coupling? I realise that any method would invariably be slower in terms of execution, but this is merely out of curiosity.
Solved! Go to Solution.
05-07-2014 09:25 AM
I guess you could save the current state of the controls in question, reset those controls to ther default values and then compare.
05-07-2014 09:27 AM
I think that this method is reasonably supportable if you document it properly and it works for me. Other devs don't tend to change default values of controls without a reason.
That said, the Control class does have a Default Value property, but I believe that's private and it may not work when you build an EXE.
If you want something that's more explicit you can build a polymorphic VI - have one version of the VI with the input and one without. The main problem with this is that the users can't know that the input is there for them to wire it without looking at the instances of the polyVI, so I still prefer the invalid value method.
05-07-2014 09:30 AM - edited 05-07-2014 09:31 AM
Last time i checked my property node for at least numeric controls, i saw a "default value" property.....
Norbert
EDIT: tst nailed it: Default Value property is part of VI scripting and therefore can lead to some constraints...
05-07-2014 09:37 AM - edited 05-07-2014 09:38 AM
Tardy post
05-07-2014 11:52 AM
Thanks tst.
I was thinking more of future expandability and use rather than maintenance.
The default value method works for any input for which you can define a default value, so it can be used for anything your imagination stretches to. This may be a trivial example, but I can foresee someone in the future copying the architecture and ignoring the documentation.- but that's my problem, not anyone else's!
As I mentioned, it was mostly out of curiosity rather than an actual wish to use it. I'll have a look at the default value via scripting for posterity, but if you were going down the scripting route you could also use the Terminal Checker method. This doesn't work in the RTE either, though.
Thanks again!