Dialog Box simulation without interrupting program flow

Question

I'm developing data acquisition/control software and need to give the end
user flexibility to change the file to which the acquired data is being
saved during operations. In the past, users have been confused with a
simple string control that specifies the data file path, so I would prefer
to move to the popup/dialog box standard to windows. Unfortunately, calling
a dialog box results in the stoppage of program flow for the caller until
the dialog box is closed (even though there may be no apparent data flow
from the popup VI.) and stopping the program flow is not an option for this
control system (the computer is controlling pressure, temperature, flow
rates, etc of a very expensive and sensitive bit of hardware, so halting the
control function for an unknown length of time is unacceptable).
I am looking for the best way to accomplish this under LabVIEW 6i.
Using a VI class reference through VI Server, I can essentially detach the
popup window from the base program execution, spawning a separate
application and passing the relevant parameters through judicious use of
global variables. If I call the subroutine via VI server with "Wait until
done" attribute set to false, the appropriate VI appears, functions
correctly, and terminates as expected. Unfortunately, it remains visible on
the screen, an inactive application. I have the VI Properties -> Window
Appearance -> Customize -> Show Front Panel When Called and the Close
Afterwards if Originally Closed checkboxes checked on this popup VI. It
seems that calls through VI Server trigger the "Originally Open" flag, so
the window does not close as I had expected.
The way I have found to get around this problem is to use VI Server to call
an intermediate subroutine whose front panel is not displayed and whose sole
purpose it to call the subroutine that calls the dialog box. This does what
I wanted, essentially. When the user wants to change directories, they
press a button that triggers a call to VI Server to open a separate
application. This application's front panel is never displayed and only
calls a sub-VI that performs all the actual work and ends when it is
completed. As this sub-VI terminates, all visible traces of the subroutines
disappear and I'm left with just the primary program executing, continuing
to take and send control signals through this whole process.
This seems a rather cumbersome way to get a custom dialog box on the screen
without stopping the program flow of the caller, however. Is there a more
efficient way to accomplish this?
Wade C. Eckhoff
[email protected]

Answer 1

Wouldn't it be easier to use two parallel independent while loops in the
main vi, with one taking care of acquisition and the other of user
interaction.
When the UI loop is temporarily 'halted' because of the dialogue box poping
up, the acquiring loop continues without delay.
Regards
Harrie Boonen
www.novonordisk.com
"Default User" wrote in message
news:[email protected]...
> I'm developing data acquisition/control software and need to give the end
> user flexibility to change the file to which the acquired data is being
> saved during operations. In the past, users have been confused with a
> simple string control that specifies the data file path, so I would prefer
> to move to the popup/dialog box standard to windows. Unfortunately,
calling
> a dialog box results in the stoppage of program flow for the caller until
> the dialog box is closed (even though there may be no apparent data flow
> from the popup VI.) and stopping the program flow is not an option for
this
> control system (the computer is controlling pressure, temperature, flow
> rates, etc of a very expensive and sensitive bit of hardware, so halting
the
> control function for an unknown length of time is unacceptable).
>
> I am looking for the best way to accomplish this under LabVIEW 6i.
>
> Using a VI class reference through VI Server, I can essentially detach the
> popup window from the base program execution, spawning a separate
> application and passing the relevant parameters through judicious use of
> global variables. If I call the subroutine via VI server with "Wait until
> done" attribute set to false, the appropriate VI appears, functions
> correctly, and terminates as expected. Unfortunately, it remains visible
on
> the screen, an inactive application. I have the VI Properties -> Window
> Appearance -> Customize -> Show Front Panel When Called and the Close
> Afterwards if Originally Closed checkboxes checked on this popup VI. It
> seems that calls through VI Server trigger the "Originally Open" flag, so
> the window does not close as I had expected.
>
> The way I have found to get around this problem is to use VI Server to
call
> an intermediate subroutine whose front panel is not displayed and whose
sole
> purpose it to call the subroutine that calls the dialog box. This does
what
> I wanted, essentially. When the user wants to change directories, they
> press a button that triggers a call to VI Server to open a separate
> application. This application's front panel is never displayed and only
> calls a sub-VI that performs all the actual work and ends when it is
> completed. As this sub-VI terminates, all visible traces of the
subroutines
> disappear and I'm left with just the primary program executing, continuing
> to take and send control signals through this whole process.
>
> This seems a rather cumbersome way to get a custom dialog box on the
screen
> without stopping the program flow of the caller, however. Is there a more
> efficient way to accomplish this?
>
>
> Wade C. Eckhoff
> [email protected]
>
>
>