What determines which monitor a dialog shows on?

[drjdpowell]

I have an application where the "second monitor" of the Windows computer is actually a projector, used in running a test.  I display test patterns on this monitor, but the User can't see them.  The problem I am having is ensuring that all dialog boxes, including error dialogs, show up on the primary screen always.  But, intermittently, they start to show up on the projector.   I cannot seem to discover how Windows/LabVIEW decides which monitor to show dialogs on.   Does anyone know?  

[hooovahh]

I also was a bit frustrated by this some times.  So attached is a demo of some panel movement code.  It has a few main functions. 

The first is sometimes I'd have a dialog I wanted to pop up, but I wanted it to be centered on whatever monitor the mouse was on.  My thought was that this was the monitor the user was using, and they probably just clicked something, so put it there. 

I also had times that I would pop up a dialog under the mouse and so I wanted the panel to be centered on the mouse as best it can, but stay on the same monitor.  This doesn't always work well with taskbars that can be hidden, and size and position not being consistent but it mostly works.

And lastly I sometimes had a need to set a panel to maximize on a specific monitor.  We typically would have 2 or 3 set side by side in the system.  So this VI can set a panel to maximize on the "Primary", "Left", "Right", "Second from Left" or a few others.

As you noticed this won't fix LabVIEW native dialogs, and any solution I can think of for those will be a bit hacky.

Panel Movement Center Maximize Demo.zip

[bjustice]

Thanks Hooovahh, I love this.

When do you typically use "Floating" vs "Modal"?

[hooovahh]

I don't like VIs to be set to Modal in the VI Properties.  I actually have a VI Analyzer test to find these.  This is because when the VI reserved to be ran, but the panel is open, it will be modal, but also not running.  In this situations aborting gracefully is difficult, and needs either an Abort All VI set to run when opened, or something like my Tray Launcher.  Because of this I have very few modal VIs in my code, and instead I will set them to modal using VI server when the VI is running.  If I have a VI that I want to be Model when it is running, I will set it with something like a constant of True when calling those panel manipulation VIs.  I guess that's a long way to say "For debugging benefits".

As for what VIs do I want to be Model?  I'd say things that are dialog settings that need to be filled out now.  If my user presses Start Test a dialog comes up asking about the details of the test to be ran, and that dialog is Model.

[jacobson]

So when you start your "Modal" VI you'll just set the FP.Behavior to Modal and set it back to Default when the VI finishes executing?

I never thought of doing that but seems worth doing it to prevent ready to run modal windows forcing me kill LabVIEW.

[hooovahh]

5 minutes ago, jacobson said:

So when you start your "Modal" VI you'll just set the FP.Behavior to Modal and set it back to Default when the VI finishes executing?

Yup.

[drjdpowell]

I set the VI to Modal inside a Conditional Disable so it applies in a EXE only, which lets me debug in source code while the dialog is open.

[bjustice]

I found this DMC slide.  I wasn't quite sure when to use Floating vs Modal, and this helped me a bunch.

In my situation right now, I like and am going to use Hoovahh's code to set to modal through VI server.  Graceful.  I really do appreciate this code that you shared.

https://www.ieee.li/pdf/viewgraphs/user_interfaces_in_labview.pdf

[Neil Pate]

That DMC deck is quite nicely done, thank you for sharing it.

[bjustice]

On 7/22/2020 at 6:00 AM, hooovahh said:

I also was a bit frustrated by this some times.  So attached is a demo of some panel movement code.  It has a few main functions. 

The first is sometimes I'd have a dialog I wanted to pop up, but I wanted it to be centered on whatever monitor the mouse was on.  My thought was that this was the monitor the user was using, and they probably just clicked something, so put it there. 

I also had times that I would pop up a dialog under the mouse and so I wanted the panel to be centered on the mouse as best it can, but stay on the same monitor.  This doesn't always work well with taskbars that can be hidden, and size and position not being consistent but it mostly works.

And lastly I sometimes had a need to set a panel to maximize on a specific monitor.  We typically would have 2 or 3 set side by side in the system.  So this VI can set a panel to maximize on the "Primary", "Left", "Right", "Second from Left" or a few others.

As you noticed this won't fix LabVIEW native dialogs, and any solution I can think of for those will be a bit hacky.

Panel Movement Center Maximize Demo.zip 97.17 kB · 35 downloads

@hooovahh I find myself using this code for so many things that I do.

I feel like it makes sense to build this into a little VIPM package.  (Especially since I'm about to release a package to VIPM that uses this code.)

If I were to turn this into a VIP, is there an appropriate way for me to credit you?

[hooovahh]

On 2/10/2023 at 7:07 PM, bjustice said:

If I were to turn this into a VIP, is there an appropriate way for me to credit you?

Anything is fine.  Just mentioning Brian Hoover (Hooovahh) in the VI description, and possibly linking to this thread in would be fine.  I put it out with no restrictions.  That being said there is a very small chance that some day I will release a Dialog & User Interface pack on VIPM.IO which could include this.