Using JUCE 2.0.21, AlertWindow::showYesNoCancelBox creates a window that floats on top of all windows from all running applications (on Mac OS X 10.7.4). In other words, if my software pops up one of those alert windows, then I switch to another application, the JUCE alert window still shows on top of any windows brought to front by the other application. Which is a bug, the alert window should not be showing on top of other application windows that are more front.
Try the tip, I don’t think this happens any more. I just tried it with the Introjucer “save on exit” “yes, no, cancel” box and this correctly stays behind other application windows on 10.7.4.
Hmmm, the problem still definitely exists for me using the latest tip and Mac 10.7.4.
Is this a plugin or an app? Plugins do set the window to be always-on-top, because a lot of hosts have windows which are always-on-top, meaning that the box could get stuck behind them.
Ah sorry to have not specified that, but yes it’s a plugin. Is there really no way to make it successfully application top rather than system top? Like how native alerts work? It is a significant user experience problem, enough to make it not suitable for release software, would be great if the problem could be resolved.
I would use NativeMessageBox::showYesNoCancelBox except that it does not offer the same flexibility for allowing you to set the text of the buttons (that also would be a nice addition, and create consistency between both showYesNoCancelBox methods).
Thinking about it again now, I think I might actually remove that always-on-top setting. If you have problems with your app’s windows getting obscured, then you can always turn it on explicitly. Seems a bit hacky for me to have always enabled it.
Sounds great to me, thank you Jules.
The best thing is to avoid ANY modal behavior in plugins. Because if a host window hides a modal plugin window the whole app may becomes unresponsiv.
This was the reason for it: http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=5575
I am not sure that changing this behaviour is a good idea: it sounded sensible the way it was done before as well, and if one relies on the static methods of AlertWindow to quickly display a message (I do), there is no way to have this message displayed always on top: the AlertWindow instance is created internally and it’s impossible to setAlwaysOnTop it
i’m also against changing the behavior. Better change the plugin not pop up an alert window in a situation where no user-interaction with plug-in gui takes place!
Jules, any words about this?
Not sure, really… There are arguments both ways. We could vote on it?
What about an additional boolean argument that chooses the behaviour instead of voting? So everyone “votes” the solution he likes more in code
There has been no word or commit about this yet, while it is causing issues to other developers too: http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=10110
jules, you are always very careful not to change anything that may break builds or behaviour in existing code, but this clearly has been the case in the first place, and silently reverting it the way it used to be may produce equally undesirable side-effects.
I think this could be easily fixed adding an explicit parameter to specify the desired behaviour. It will break some builds out there but it will be very easy to fix once it’s spotted at compile time. It’s much harder to track down the source of the problem if one doesn’t know about it and suddenly all the AlertWindows fall behind the main plug-in window.