SubVI with modal window behavior/window appearance

[DaVinzi]

Hello everyone,

Welcome to my first post with which I hope to not embarrass myself

I'm currently working on an application in which my main-VI produces a pop-up on startup. It is implemented such, that the main-VI simply calls a SubVI in which I use according invoke- and property-nodes to make sure that the frontpanel is shown in the correct size/postion/etc. - you konw the drill.

The pop-up contains a list of checkboxes that the user has to check manually - it is a checklist in that sense. Once he completed checking the appropriate boxes the user can close the subVI frontpanel and continue with the actual application.

I have set the "window behavior" (VI Properties>Window Appearance>Customize) to "modal" since I want the frontpanel to be frontmost and obligatory to complete before he can continue on the main-VI.

However, here is my problem:

After building the application/installer, when I run the application the pop-up does show up, but the window is not showing modal behavior, i.e. without even completing the checklist I can already use the application in the main-VI.

I assume, when the application is built/run, only the VI properties of the main-VI are considered relevant for the execution and the VI-properties of the subVI are not even registered.

So how can I make sure, that the subVI frontplanel behaves as intended in the final application?

Cheers, and I hope I provided the necessary information to give you an idea of the issue.

Vinz

[Yair]

First, Welcome to LAVA.

Second, The properties of the subVI should definitely be remembered in the application if you customized them. Assuming things are working correctly, you should only see something like this under specific circumstances:

1. The main VI is also modal. This shouldn't actually make difference, because if both are modal, the subVI should "win".
   
2. You change the properties of the VI in code.
   
3. You changed the properties of the VI when building the application. This also doesn't seem likely, because it would require explicit actions, but it's also something I would check. It should be found in the Source Files Settings page of the app builder. Selecting the VI and clicking the customize button allows you to change these settings for the build, but again, that should not be needed.
   

I would suggest you check all of these to see if they apply. If not, uploading the code should help, or you could also try starting from scratch (e.g. create a new build spec just to test this).

[DaVinzi]

Hi Yair,

Thanks for the input so far!

So, I just double and triple checked the three points you mentioned:

1.) The main VI's Window Behavior is set to "Default".

2.) I don't access/modify/call any properties/methods of main- or sub-VI prior the point when I call the subVi.

3.) The Source File Settings of the main VI are set such, that it exclusively uses the set VI properties and doesn't overwrite any parameters of the window appearance. In the application builder I cannot customize the VI properties of the sub VI, which I assume is normal as it is "only" a sub VI and not the main VI.

Due to customer confidentiallity I'm afraid I cannot simply upload the source code, but if I shouldn't figure out a solution soon I will create an example-version of the pop-up functionality as I have implemented in this project.

----------------------

edit: On a sidenote. I can't really operate the application in the main VI. It does wait for the subVI conclusion. But running the subVI "modal" should not even allow doing anything on the main VI front panel.

Edited November 18, 2011 by DaVinzi

[asbo]

So what behavior are you actually seeing the main window? You can click buttons and the like but they don't actually do anything?

I don't have any better ideas than Yair, but if you have to work around this issue you can use the Controls[] property of your panel and just disable everything before calling the subVI.

[Rolf Kalbermatter]

Hello everyone,

Welcome to my first post with which I hope to not embarrass myself

I'm currently working on an application in which my main-VI produces a pop-up on startup. It is implemented such, that the main-VI simply calls a SubVI in which I use according invoke- and property-nodes to make sure that the frontpanel is shown in the correct size/postion/etc. - you konw the drill.

The pop-up contains a list of checkboxes that the user has to check manually - it is a checklist in that sense. Once he completed checking the appropriate boxes the user can close the subVI frontpanel and continue with the actual application.

I have set the "window behavior" (VI Properties>Window Appearance>Customize) to "modal" since I want the frontpanel to be frontmost and obligatory to complete before he can continue on the main-VI.

However, here is my problem:

After building the application/installer, when I run the application the pop-up does show up, but the window is not showing modal behavior, i.e. without even completing the checklist I can already use the application in the main-VI.

I assume, when the application is built/run, only the VI properties of the main-VI are considered relevant for the execution and the VI-properties of the subVI are not even registered.

So how can I make sure, that the subVI frontplanel behaves as intended in the final application?

Cheers, and I hope I provided the necessary information to give you an idea of the issue.

The recommended way to do what you want to do, without even having to issue VI server calls to open and size the window is to simply select under Windows Appearance in the VI settings the Dialog option. This will change various specific settings, such as Show FP when called and close afterward, modal state, disable scroll bars and a few other things. Especially under Windows, some of these properties are exclusive, meaning that if you enable or disable one of them you also disable or enable something else automatically, and LabVIEW can't even do anything about it.

You still can execute code to size and place the dialog if you need to, but should try to minimize the number of programmatic changes to window style modifications as much as possible, as they can unset settings you made in the configuration implicitly.