test "recommended" input

[psilviu]

I have a vi with a "recommended" type input. This pin is also boolean. How can I test / find out (in this vi) whether this input is actualy connected to anything (in case that this vi is called from another one)? I could simply test its value to see whether it is over writen, but this doesn't help when the upper vi aplies to this vi's input the same value as the existing / default value I have in this vi.

Thank you guys,
Silviu

[smercurio_fc]

You should not base the operation of a VI on whether or not an input is wired. It should be based on the value of an input. A subVI should operate in an atomic way. If you want that input to be wired then it should be set to "Required". Otherwise, the VI should not care whether or not the input is wired. It should only care about the value. In the case of a Boolean it's either True or False. That's it. For a numeric you can, set the default value of a numeric to NaN. Then in your code you can check to see if the value of the numeric is NaN, and if so you can use a default value internally. This is sort of testing to see if the input is wired, but the upper level VI could just as well have wired a constant of a value of NaN and the subVI wouldn't know the difference. Again, it's the value that matters.

[RavensFan]

---

smercurio_fc wrote:
You should not base the operation of a VI on whether or not an input is wired. It should be based on the value of an input. A subVI should operate in an atomic way. If you want that input to be wired then it should be set to "Required". Otherwise, the VI should not care whether or not the input is wired. It should only care about the value. In the case of a Boolean it's either True or False. That's it. For a numeric you can, set the default value of a numeric to NaN. Then in your code you can check to see if the value of the numeric is NaN, and if so you can use a default value internally. This is sort of testing to see if the input is wired, but the upper level VI could just as well have wired a constant of a value of NaN and the subVI wouldn't know the difference. Again, it's the value that matters.

---

Smercurio,

I agree that the input should be made required.  I think there would still be an issue if the poster uses the NaN as default method.

If you have two copies of the sameVI which as the default as NaN.  If one copy sets the value to something else by a wired connector, then later another copy of the subVI runs with an unwired connector, wouldn't the subVI have the value stored in the control from the first run which was not NaN.

[JeffOverton]

---

Ravens Fan wrote:

If you have two copies of the sameVI which as the default as NaN.  If one copy sets the value to something else by a wired connector, then later another copy of the subVI runs with an unwired connector, wouldn't the subVI have the value stored in the control from the first run which was not NaN.

---

I think that would only be the case with a USR.  The default will always take place if there is no value wired, otherwise the USR wouldn't be a special case.

edit - a quick test confirms this

Message Edited by JeffOverton on 06-06-2008 01:23 PM

[RavensFan]

You're right.  I was getting the behavior confused with how the previous values stay in a control when you restart a top-level VI.

[tst]

There is currently no way to know for certain whether or not the input was wired (not even using scripting). It can be done using some black magic (heavy XNode usage), but that is NOT for use in production code. Just make the input required or use an enum instead of a boolean.

---

smercurio_fc wrote:
You should not base the operation of a VI on whether or not an input is wired.

---

There are times when doing it can be very beneficial. For example, consider what happens when you drop a property node - it defaults to the current application instance. The same thing if you change it to the VI class. This is very useful if you want to create "brat" VIs (VIs that control their parents. I believe the term is Norm Kirchner's) or VIs that have a legitimate default behavior. Here's an example. Of course, that won't work with a boolean.

[smercurio_fc]

I make the distinction between a default value of a control, which I agree is beneficial, and testing whether or not something is wired. The latter seems to be more for checking that, say, a programmer didn't miss connecting something that they should have. The former is for allowing a VI to run using reasonable values for controls even if the programmer didn't connect a constant or control to the input. There's tons of examples of those, obviously.

[Ben]

Stepping back and thinking...

If you have a VI that has an optional input that you want to make usre is used correctly, then perhaps you should NOT trust other developers to use it correctly and instead place that VI in two wrapper VI's, one where the optional input has a contant wired to the "optional input" but who's icon connector does NOT have the terminal of interest, and another that does include the terminal of interest and make all of this second wrapper's input required.

By using the warppers you don't have to trust the developers to wire it up correctly.

Use of libraries and public vs private VI's will help enforce proper use.

So, don't worry if the terminal was wired, make sure it is!

Done thinking,

Ben

[psilviu]

Hi Ben,
I'm not sure I understood your method. Could you give a small example?
Silviu

[Van_L]

I think what Ben is trying to say is the following:








Message Edited by Van_L on 06-11-2008 08:50 AM