By definition, modal windows are to be the front most window and block access to other windows in an application. Sounds like you should just stop using modal dialogs except in rare occasions.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
I know how a modal window works. But this behaviour makes Labview GUIs one directional and limited. I generally use modal behaviour for parameter setting windows. Not only for user dialogs. I block rest of the application to prevent the user access. But if I want some floating palettes, some context menu style or dropdown menu style forms it is not possible to design one. All you have to do is to make another modal form and open it close it each time you need. Or you have to add all functionality to the same form. Like smartballon library. I want an accessible logger, informational, etc processes that should be accessible independent from the rest of the application even there are modal windows.
>But if I want some floating palettes, some context menu style or dropdown menu style forms it is not possible to design one. All you have to do is to make another modal form and open it close it each time you need.
Been there...
I have a custom menu (because we (still) can't have icons in right click menus). But the menu consists of floating windows, for nit-fiddling reasons. The floating windows don't appear above modal windows though.
I now detect VI activation, and if the activated VI isn't my 'fake modal' window, I activate my fake modal window. I also discard the mouse click in the clicked VI.
We do need more flexibility here, but simply ignoring modal settings is a bit crude, I don't think it will hold. It seems it will require a z ordering system, where a window is modal relative to some z value. I'm sure there is some precedence in other GUI systems.
>We do need more flexibility here, but simply ignoring modal settings is a bit crude, I don't think it will hold. It seems it will require a z ordering system, where a window is modal relative to some z value. I'm sure there is some precedence in other GUI systems.
Why we can't simply ignore owning (parent) window behaviour? We need a checkbox "ignore parent (owning) VI behaviour" at the window appearence options.
Edit: Also the option should be "ignore all window behaviours". Or both...
@Zafer.Depe wrote: Why we can't simply ignore owning (parent) window behaviour? We need a checkbox "ignore parent (owning) VI behaviour" at the window appearence options.
It would be nice to have an option for newly opened FPs should ignore previously opened modal FPs.
Edit: Or give an option for floating FPs to skip (ignore) all modal FPs.
The parent\child relation of VIs is, at the moment, not at all like that. For instance, a dynamically started VI has (almost) nothing to do with the 'parent' that called it.
