Community Nugget, 05/27/2007

[tst]

Today, a useful tip:

On occasion, it could be very useful to have a VI know whether one of its inputs was wired or not.
For example:

1. You could have a VI which will accept a path, or pop up a file selection dialog if you haven't wired the path input.
2. You could have a LV2 style global which would execute its Write case automatically if you wired something into it.
3. You could have a utility VI which will operate on the VI calling it unless a reference to another VI was given to it.

The possibilities are endless.

LabVIEW does not currently expose a way of letting us know whether an input was wired in the calling VI or not, but there is a workaround. When you don't wire a value into an input control, that control uses its default value. For many datatypes, you can determine as default a special value which would be considered invalid and then check if the control is equal to that value and assume that the input control was not wired if is equal to that value.

Consider the following code, for instance:

If a VI reference was wired, the VI will control the defer property for that VI. If no reference was wired, it will control the defer property for the caller, so to control the defer property in your VI, you just have to drop it in the block diagram of your VI.

Common invalid values include -

• NaN for floating point values
• an empty (invalid) reference for references (VIs, controls, etc.)
• negative numbers for numbers which should only be positive
• a special invalid value for enums.

Now go out and be creative.

P.S. You should note that it is important to choose a correct invalid value.
NaN, for instance, can be achieved through calculation (e.g. through dividing by zero).

For a list of past nuggets, see here.

If you want to write nuggets yourself, see here.

[tst]

Just a point I noticed about that (very quick) example - the Defer Updates input should probably be a required input and in any case should not be T by default, because that would make the FP get stuck.

Attached is a simple example demonstrating its use. When the OK button is changed, the updates are defered for several iterations.

[ohiofudu]

Hi tst,

Nice Nugget keep the good work.

CLAD

[Ben]

Good Nugget tst!

I use this approach often and generally enunciate an error if the default is discovered.

Ben

[Ray.R]

Thanks for the Nugget tst!

It is interesting and got me thinking... I may be using this in the future..

RayR

[dan_u]

Thanks for the nice nugget. I was missing the "unwired" information for VI connectors, but didn't think of this workaround.
Also, your nugget gave me some ideas where we could use this.

Daniel

[tst]

---

@Ben wrote:

I use this approach often and generally enunciate an error if the default is discovered.

---

So why not just make the input required and that way you "should" never get default values?

The point here was to use the default for additional functionality where it would make sense and the user does not wire anything in (like working on the current item, remembering past values, etc.).

Do other people have good examples of this?

[johnsold]

Thanks for the tip. I have done some similar things on occasion, but you have suggested several new options.

Is there any way to detect when a variant is empty? I had program where this would have allowed a shift register to pass the old value if no new value was present. The underlying datatype did not have an invalid condition which could be used to detect this post-conversion. I ended up passing an additional parameter outside the variant to signal this condition, but it seemed an awkward work-around.

Lynn

[Darren]

---

@johnsold wrote:

Is there any way to detect when a variant is empty?

---

Check out Darren's 2nd Weekly Nugget...you can use the Empty String/Path? function.

-D

P.S. - Someday, the on-line help for Empty String/Path? will indicate that it works on variants, pictures, etc.

[johnsold]

Darren,

Thanks.

I thought I had tried that. I will check it again when I get a chance.

Lynn