How to know if a wire is connected to a control (in the case of subVI)?

[R0b1n]

Hello,

I would know if it is possible to know if a wire (in the caller VI) is connected to the subVI control ,or not.

- There is any function to test a control to know if it is wired in the caller VI, or not ?

OR

- Do I test control defaults values and determine if a wire is connected ?

I hope my question is understandable 😃

Rob

[Coq_Rouge]

Hi

I am not sure if this is of any help. But if click on a connector in the connector pane. You can specify some options. I often use the "is required" option for important input data. If a connector of this type is not wired. An error and a broken arrow will be the result. The VI will not run before the problem is corrected.

Message Edited by Coq rouge on 05-04-2009 10:51 AM

[R0b1n]

Thx,

Ok, I set my conector to "Optionnal" : there is a way to know if a wire is connected to a wire ( in the caller VI). The option required does'nt resolve the problem.

Any other ideas ?

Thanks

Rob

[johnsold]

Rob,

I am not aware of any way to tell directly whether a control is wired when the VI is called.  If there is a value of the input which can never be generated by the caller, make that the default  value and check to see what value is on the terminal when the VI is called.  If default, then unwired.

Why do you need this capability?  Is the VI used in multiple places and the control wired in some but not others?

Lynn 

[Ben]

---

johnsold wrote:

Rob,

...

Why do you need this capability?  Is the VI used in multiple places and the control wired in some but not others?

Lynn 

---

Good Q Lynn!

Ben

[elset191]

I've needed to know this because in one of my VI's, the first time it is run there are certain values (Potentially different across runs).  Then after the first time I use the last values the user selected. 

I used the method of having an illegal default value and comparing the inputs to the defaults, as was suggested.

Message Edited by elset191 on 05-04-2009 08:59 AM

[johnsold]

Consider also the First Call? primitive connected to a case structure inside your VI.  This may be a more robust means of detecting what you want to know.

Lynn 

[Ben]

Hi Tim,

In the post mortem discusion of one of my Nugets Jim Kring offered a wonderful idea that I have since adopted. In that discussion we were dealing with the quesion of using "required" on all of out inputs but in the case of a an Action Engine where different inputs were required in different actions, there seemed to be a catch-22 in that we could not expect the use of of our AE to propvide all inputs for all actions.

Jim's suggestion was (as I understood it) to create a wrapper VI for each call to the AE. The Wrapper would be developed by the developer of teh AE since they knew what the AE needed in each action. The wrpaare would only have inputs for those values used by that particular action and it would provided constants for all of the required inputs of the AE.

This gives AE's a kind of LVOOP look and feel because the AE becomes a "core" method that is only accesable by memebers of the same library while all of the wrappers (one for each action) become public methods that in-turn call the AE the right way.

Using thios approach I never find myself wondering if an input was wired because I know it has to be wired.

Just trying to help,

Ben

Message Edited by Ben on 05-04-2009 09:17 AM

[DFGray]

Ben, if you are going to that much trouble, you are better off using single-element queues than action engines.  This essentially eliminates the maintenance on the action engine and distributes it among the accessors/functions, where it is easier to handle and much more scalable.  It is more object-oriented, which is why I prefer it.  It is also faster and more efficient when it matters (large data sets).  I use action engines when I don't want to write a lot of accessor functions (e.g. an error stack/propagation mechanism).

[Ben]

HI Dr Gray!

I am slowly moving that direction (changing old habits is like trying to turn a battleship) but when I read threads like Garys on LAVA I hold course and keep the wheel fixed.

I benchmark each code construct one by one to convince myself I am not lettting a non-optimal pattern into my collection.