Duelling Dialogs

[drjdpowell]

Does anyone have a solution to the problem of ordering of floating windows, where for example a modal dialog box is behind another floating window, and thus can never be dismissed?  Or a floating window opens a file-selection dialog, and it opens behind the first window.  Is there a way to determine which modal window has control (and must be dismissed first) and then force that to the front?

[Neil Pate]

James, not exactly solving your problem, but...

What I usually do is only make the dialogs modal during exe building (i.e. set their FP property in the build only). This prevents the issue of things being hidden behind other things and locking the developer out of LabVIEW.

[drjdpowell]

I do that.  But the problems I have are reported by Users of the EXEs

[Neil Pate]

Now that you mention it, I recall a work around I had to put in place some time ago on a touch screen only application. Sometimes my custom dialogs got hidden behind the main panel, the way we solved it in the end (ugly but worked), was just to periodically force all the dialogs to be on top. Each dialogue type actor was responsible for getting itself on top. Not pretty...

[drjdpowell]

The problem is, if there are two dialogue actors, which should be on top.  Only one dialog can be interacted with, but that one isn't necessarily on top.

[Gribo]

Here are my ugly hacks:

1. Only one active panel at a time. If user input is required for a dialog, it is on top, all other panels are disabled.
2. In Windows, a system call to bring the window on top is used, instead of LV's bring to front. This gets me somewhat more consistent results than the LV function.
3. If there are two (or more) active panels, the newest one is enabled, the others are disabled.