Returning Data From a SubVi

[Tyler Shogren]

Hi,

I'm currently modifying a medium complex app and I'm trying to use a SubVI to help improve the Main VIs readability. Currently I am trying to replace a part of the program and first makes visible two numerical controls, three boolean controls and a buton, loops until the buton is pressed (until the user enters data in the controls and presses the button), then makes these same controls invisible. The data in these controls are then used in the rest of the program. I would like to replace this structure with a single sub vi with the same controls so that it pops up, the user enters data and then closes the subvi with a button, passing the entered data to the main program. I am currently having issues because the connector pallete seems to only accept inputs (despite the word "output" frequently occuring in the help documentation). I suspect I might need indicators instead of controls to wire outputs, but this is counterintuitive, because indicators should indicate inputed data, not outputing data. And anyway, that won't help me collect data from the user. I want to avoid setting visibility and I want to avoid looping until the buton is pressed. Can anyone address this specific issue or make a better suggestion of how to implement this?

-Tyler Shogren

[ned]

The way I've always done this, and I believe it's the standard approach, is to put controls on the front panel along with matching indicators. Wire the indicators to the connector pane, then hide them. On the block diagram, wait until the user presses the button (using a loop or an event structure), then pass the values from the controls to their corresponding indicators. Make sure that the copy from the control to the indicator happens only after the button is pressed.

If you use an event structure, be warned that sometimes events may not fire in exactly the order you expect. In particular, say you allow the "Enter" key to toggle your button. If you enter a value into a numeric control, then hit Enter, the boolean event will fire before the value of the control is officially changed. So, if you copy the value of the numeric control into an indicator in the boolean event case, you'll get the previous value of the numeric. Don't worry if this doesn't make sense to you - if you do use an event structure and your numeric values are inexplicably wrong, look back on this post and it will probably make more sense.

On a side note, does anyone else ever use an event structure outside a loop when you just want a VI to wait until a single event (Window close, button click, etc.) occurs before terminating the VI?

[Ton Plomp]

QUOTE (ned @ Jun 9 2008, 08:11 PM)

The way I've always done this, and I believe it's the standard approach, is to put controls on the front panel along with matching indicators. Wire the indicators to the connector pane, then hide them. On the block diagram, wait until the user presses the button (using a loop or an event structure), then pass the values from the controls to their corresponding indicators. Make sure that the copy from the control to the indicator happens only after the button is pressed.

For the sake of being honest sometimes I just create an express VI, and then convert it into a normal VI and customize.

Instead of hiding I create a user-visible part inside a decoration, and with OpenG functions I limit the visible part to this decoration.

QUOTE

On a side note, does anyone else ever use an event structure outside a loop when you just want a VI to wait until a single event (Window close, button click, etc.) occurs before terminating the VI?

Yes, see http://wiki.openg.org/Wait_for_value_change' rel='nofollow' target="_blank">here. (and give your support in the accompanying forum).

Ton

[Yair]

I would agree with the notion of not hiding indicators. I set the front panel origin to 0,0 and always place the controls and indicators which should not be visible above that line. That leaves room to expand the FP downwards.

[crelf]

QUOTE (tcplomp @ Jun 9 2008, 02:28 PM)

Instead of hiding I create a user-visible part inside a decoration, and with OpenG functions I limit the visible part to this decoration.

That's the best way to do it - and then, if you like, you can use an OpenG function to rezie the FP to all contols/indicators at the end of execution. It's bad form to hide FP nodes unless you really need to - if you don't want the user to interact with them, it's often better to make them disabled and grayed.