Is control in subvi wired?

[MU123]

Just wandering if there is a way for a sub vi to tell if a control is wired when it was called.  I know that if it is not called it will use the default value. 

So if I have a Boolean control as an input to a vi, I want to know inside the vi whether the terminal was wired or not.  I know it will get the default value that I set up in the vi for the control if it is not wired.  I've looked for a property of the control using a reference but didn't see anything obvious.

Thanks,

Mike

[RavensFan]

No.

http://forums.ni.com/t5/forums/searchpage/tab/message?location=Node%3A170&q=connector+unwired#messag...

[vt92]

If it is really important to you, post a suggestion on the idea exchange:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas

[MU123]

OK.  Thanks for the quick response.  I couldn't find those when I searched.

Thanks,

Mike

[paul_a_cardinale]

You can use a variant control, and check if it's void.

[Ben]

...or just mark the input as required thereby removing all doubts.

Ben

"A wise man  may keep silent and appear a fool, while a fool speaks his mind and removes all doubts" (Paraphrase Proverbs)

[SteveChandler]

What I do is to make the default value of the control something that is very unlikely to be sent to the subvi. If it is a string make the default value something like "this-control-is-not-wired-because-this-is-the-default-value". If it is a number then make the default value way outside of the range you expect. You could make it NaN if you do not expect that.

[Darin.K]

I am not one to take no for an answer, so I played around with this once.  The return on hacking investment is very small.  I can now do this quite easily with XNodes...

BUT

My personal opinion is that this is a TERRIBLE appproach, and it is annoying almost everywhere LV uses it.  (It is ok for array indexing functions, but there are still better ways IMO).   My classic peeve are the file functions which give you a dialog when the input is unwired: I could save many, many case structures and Express VIs if that same dialog would be triggered by an empty path or Not a Path, but no, only by wiring or unwiring the input.  Not exactly a Game-time decision.

My advice is to limit your decision making to what is inside the wires, not the absence or presence of wires.  The usual tricks are making default values "bad" (NaN for floats, Not a Path, Empty Strings) and just do the normal checking you always do for validity of inputs, regardless of the source.  Making the input required is also a useful suggestion, particularly for booleans which don't have a 'bad' value.

[MU123]

That's what I was thinking for strings, DBLs, path's and such.  Just not many choices when dealing with a Boolean to find a value I am unlikely to use. 🙂

[Ben]

See the link in my signature for a thread where Jim Kring suggested using wrappers...

If you have a VI that can be used in different ways but you want to enusre it is called corectly every time, then create a wrapper that does the correct call and make the connctors on the wrapper required. The required makes the user provide the info you need and the wrapper will ensure the sub-VI is called appropriately.

You can even go another step and put it all in a library and mark the wrappers as public to force others to use the wrappers.

Ben