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:3a3014d7@newsgroups.ni.com...
> 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
> wade.eckhoff1@jsc.nasa.gov
>
>
>
