Hi
It’s been a couple of months since I pulled from the tip, after pulling today I found that the AlertWindow is showing behind the plug-in window in OSX.
I found this thread viewtopic.php?f=2&t=9838 when Jules is considering changing the AOT behavior but I did not find any related commit message in the logs.
I found some commit logs about changes in the OSX modal behavior, but I don’t know if those are the relevant changes.
Can anybody point me to the relevant commit/change?
Thank you
Seems that we are bumping into the same problem…
Did you figure this one out?
Sure, forgot to post it when I found it:
It’s in the AlertWindow constructor
notice the //SHLOMI comment
AlertWindow::AlertWindow (const String& title,
const String& message,
AlertIconType iconType,
Component* comp)
: TopLevelWindow (title, true),
alertIconType (iconType),
associatedComponent (comp),
escapeKeyCancels (true)
{
if (message.isEmpty())
text = " "; // to force an update if the message is empty
setMessage (message);
Desktop& desktop = Desktop::getInstance();
for (int i = desktop.getNumComponents(); --i >= 0;)
{
if (Component* const c = desktop.getComponent (i))
{
if (c->isAlwaysOnTop() && c->isShowing())
{
setAlwaysOnTop (true);
break;
}
}
}
//SHLOMI: I restored that after Jules removed it in commit 06e2a667fb8fd1fbd4071a0c5fb873b47009bd79 cause In OSX the alert windows are shown behind the plug-in
if (! JUCEApplication::isStandaloneApp())
setAlwaysOnTop (true); // for a plugin, make it always-on-top because the host windows are often top-level
//ENDSHLOMI
AlertWindow::lookAndFeelChanged();
constrainer.setMinimumOnscreenAmounts (0x10000, 0x10000, 0x10000, 0x10000);
}I’ve reverted the same change and added some comments in the other parts of JUCE where it does similar things, so that I should get a conflict in case I merge a version where jules has changed something in that area.
You may find the details here:
Will Jules be merging this into the official juce repo?
Bram
I think it’d need to be a bit smarter, e.g. if it checked all the app’s windows to see if there are any other always-on-top windows present before using that mode itself.
Jules,
Would it be possible to put something simple in there right now (for example always completely on top again) and make it smarter afterwards? Or perhaps just supply something in the messagebox that allows us to put them on top of everything?
We only use dialog boxes when the user does something directly on the plugin UI, like click a button to activate. The “your activation was successful” messages appear below the plugin on osx where you basically can’t see them -if you are unlucky-. Some kind of way to force them to the front would be awesome.
FYI, the ThreadWithProgressWindow window is also displayed behind the plugin UI…
I’m a BIT behind on the tip, about a week…
I’ve added something that should handle this now, chaps, but haven’t tested it in a plugin. Would be interested to hear if it works!
hey Jules,
it took me a while but, yup, this seems to be fixed.
thx!
the AlertWindow is not the only one that should be affected by this change: there are other places (CallOutBox, DialogWindow) where the older rule “put the window on top if we are not an application (i.e. we are a plug-in, so there may be host windows on top)” was used. I think the same new logic should be applied there, too. Jules, do you think is a sensible idea?
The spots where it is used are detailed here:
Yes that’s a good idea, thanks!
Just saw the check-in of always on top detection.
Is there any chance this could remedy the problem about comboboxes that appear under the plugin window? (happens for juce plugins using comboboxes in Reaper)
http://rawmaterialsoftware.com/viewtopic.php?f=2&t=9030
yes.
But it is still not a good practice to use modal windows in plugins.
How do you guys deal with closing the windows?
If you got a modal window opened and quit the host/ destroy your plugin, it will surely crash.
You 've got a workaround for that ?