LabVIEW
Application all panels run when opened, even if set to not do that.
Hi Scotty,
there surely is a better option than "run when opened"! In an executable all vis "run when opened" as this is usual behaviour. (Do you have to "start" a word document manually when you open it?) An executable should only have one main vi which controls the subvis!
You should use your vis as subvis in the main vi and set them to "show front panel when called" and "close when finished". That's the standard way.
Next option would be to run all your vis in parallel ("run when opened") and have a wait loop in them. That's also standard procedure.
Message Edited by GerdW on 02-25-2008 04:44 PM
there surely is a better option than "run when opened"! In an executable all vis "run when opened" as this is usual behaviour. (Do you have to "start" a word document manually when you open it?) An executable should only have one main vi which controls the subvis!
You should use your vis as subvis in the main vi and set them to "show front panel when called" and "close when finished". That's the standard way.
Next option would be to run all your vis in parallel ("run when opened") and have a wait loop in them. That's also standard procedure.
Message Edited by GerdW on 02-25-2008 04:44 PM
Hi Scott,
"would I have to change all UI to add booleans to the aquisition.vi's and then have the technician "load' which panel he wanted to use?"
Either this way or you have to have a button in each subvi labeled "accept actual settings" (or similar). Or just call those subvis when needed. Or... (many other options)
Point is: in an executable each vi is (automatically) set to "run when opened". When you don't want this behaviour you have to put in some waiting loops checking a "Start" button (using an event structure to avoid cpu hogging) - or only call those vis when really needed.
IMHO it's annoying to have 5 windows open when I only need one at a time. Open the subvi's panel only when needed, change&save settings, close subvi... You will either have 4 buttons on your main vi's panel to start those 4 subvis or you may use an enum/ring control to select&call the subvi.
Message Edited by GerdW on 02-27-2008 09:59 AM
"would I have to change all UI to add booleans to the aquisition.vi's and then have the technician "load' which panel he wanted to use?"
Either this way or you have to have a button in each subvi labeled "accept actual settings" (or similar). Or just call those subvis when needed. Or... (many other options)
Point is: in an executable each vi is (automatically) set to "run when opened". When you don't want this behaviour you have to put in some waiting loops checking a "Start" button (using an event structure to avoid cpu hogging) - or only call those vis when really needed.
IMHO it's annoying to have 5 windows open when I only need one at a time. Open the subvi's panel only when needed, change&save settings, close subvi... You will either have 4 buttons on your main vi's panel to start those 4 subvis or you may use an enum/ring control to select&call the subvi.
Message Edited by GerdW on 02-27-2008 09:59 AM
I wanted to update the community with the resolution to ScottyD's issue.
In summary, Scott has an application with multiple Startup (top-level) VIs. Scott needed to build an executable that would contain all of these VIs and upon launching the executable, he needed to open, but not run those startup VIs. While many can argue this startup sequence is not a good way of creating an application, the fact remains that this is a legacy application that Scott is upgrading from LabVIEW 7.x, and that is what is operators are used to seeing. Therefore, Scott wanted to make the application as similarly behaved in LabVIEW 8.5 as the previous version of this tool as possible.
There are multiple ways of acheiving this behavior. The first one that came to my mind when talking to Scott was to use a single top level VI that programatically using VI Server opened the front panels of the multiple startup VIs. This would have required a code change for Scott, so we tried to avoid that solution.
The second method that Scott actually implemented to acheive his desired behavior was accomplished by digging a little deeper in the executable build specification. Scott's main complaint was that even though he set in the VI properties that the VIs should not "run when opened", by default, the application builder always overwrites that setting in an executable to cause startup VIs to run immediately. This is aligned with the explaination from GerdW, you never have to "start" Word.exe when you open a new document. Most users expect an application to be running when they launch an executable.
While the application builder does override the "run when opened" setting, it is always possible to override the application builder, except in LabVIEW 8.2, where it requires a little creativity ;).
Below is a screenshot which outlines the procedure to have multiple startup VIs in a LabVIEW 8.5 executable that do not run when opened:
1. Specify multiple startup VIs on the Sources Files page of the application builder.
2. On the Source File Settings page, select each of the start up VIs one at a time and click Customize VI Properties...
3. Notice in the VI Properties dialog, the "Use VI Property" option is unchecked, and "Run when opened" is enabled and checked, thus causing this VI to run when the executable is opened.
4. Uncheck the box causing the "Run when opened".
5. Repeat steps 2-4 for each Startup VI.
6. Rebuild the executable, and now you have the desired (in this case) behavior.
Cheers,
Message Edited by Spex on 03-03-2008 07:58 AM
In summary, Scott has an application with multiple Startup (top-level) VIs. Scott needed to build an executable that would contain all of these VIs and upon launching the executable, he needed to open, but not run those startup VIs. While many can argue this startup sequence is not a good way of creating an application, the fact remains that this is a legacy application that Scott is upgrading from LabVIEW 7.x, and that is what is operators are used to seeing. Therefore, Scott wanted to make the application as similarly behaved in LabVIEW 8.5 as the previous version of this tool as possible.
There are multiple ways of acheiving this behavior. The first one that came to my mind when talking to Scott was to use a single top level VI that programatically using VI Server opened the front panels of the multiple startup VIs. This would have required a code change for Scott, so we tried to avoid that solution.
The second method that Scott actually implemented to acheive his desired behavior was accomplished by digging a little deeper in the executable build specification. Scott's main complaint was that even though he set in the VI properties that the VIs should not "run when opened", by default, the application builder always overwrites that setting in an executable to cause startup VIs to run immediately. This is aligned with the explaination from GerdW, you never have to "start" Word.exe when you open a new document. Most users expect an application to be running when they launch an executable.
While the application builder does override the "run when opened" setting, it is always possible to override the application builder, except in LabVIEW 8.2, where it requires a little creativity ;).
Below is a screenshot which outlines the procedure to have multiple startup VIs in a LabVIEW 8.5 executable that do not run when opened:
1. Specify multiple startup VIs on the Sources Files page of the application builder.
2. On the Source File Settings page, select each of the start up VIs one at a time and click Customize VI Properties...
3. Notice in the VI Properties dialog, the "Use VI Property" option is unchecked, and "Run when opened" is enabled and checked, thus causing this VI to run when the executable is opened.
4. Uncheck the box causing the "Run when opened".
5. Repeat steps 2-4 for each Startup VI.
6. Rebuild the executable, and now you have the desired (in this case) behavior.
Cheers,
Message Edited by Spex on 03-03-2008 07:58 AM
