# DialogWindow appears behind plug-in window **URL:** \ **Category:** Audio Plugins\ **Created:** [June 7, 2010, 10:09am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359 "2010-06-07T10:09:16Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [June 7, 2010, 10:09am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/1 "2010-06-07T10:09:16Z")
Hi, I had the DialogWindow created by showModalDialog appearing behind the plug-in window in Logic, but I noticed that AlertWindows did not suffer of this bug. Digging into the code, I found that the following code does the trick for the AlertWindow: ```auto if (JUCEApplication::getInstance() == 0) setAlwaysOnTop (true); // for a plugin, make it always-on-top because the host windows are often top-level ``` What about integrating the same code into DialogWindow (as proposed below)? Otherwise, adding an addToDesktop parameter to the funcion (defaulted to false) would work equally well without changing the behaviour of existing code, but I doubt that making a modal DialogWindow appear behind some other window is of any use at all… (the proposed change requires the inclusion of “…/…/…/application/juce\_Application.h” at the beginning of the DialogWindow.cpp) [code]int DialogWindow::showModalDialog (const String& dialogTitle, Component\* contentComponent, Component\* componentToCentreAround, const Colour& colour, const bool escapeKeyTriggersCloseButton, const bool shouldBeResizable, const bool useBottomRightCornerResizer) { TempDialogWindow dw (dialogTitle, colour, escapeKeyTriggersCloseButton); ``` dw.setContentComponent (contentComponent, true, true); dw.centreAroundComponent (componentToCentreAround, dw.getWidth(), dw.getHeight()); dw.setResizable (shouldBeResizable, useBottomRightCornerResizer); if (JUCEApplication::getInstance() == 0) dw.setAlwaysOnTop (true); // for a plugin, make it always-on-top because the host windows are often top-level const int result = dw.runModalLoop(); dw.setContentComponent (0, false); return result; ``` } [/code] ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [June 7, 2010, 11:03am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/2 "2010-06-07T11:03:11Z")
Sounds like a sensible request, thanks! ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 13, 2010, 10:49am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/3 "2010-08-13T10:49:56Z")
The same happens with the new CallOutBox class BTW ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 13, 2010, 10:57am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/4 "2010-08-13T10:57:20Z")
Good point, thanks! ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 13, 2010, 11:13am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/5 "2010-08-13T11:13:00Z")
And I don’t know if it’s me or not, I should try with the plugin demo, but if I close the plugin window when a CallOutBox is active then when closing the plugin there’s an assert in ~Desktop() and ~MessageManager() saying that there are leaked Components. It doesn’t happen otherwise. ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 13, 2010, 12:08pm UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/6 "2010-08-13T12:08:11Z")
Well, if you don’t clean up the modal component when your UI gets deleted, it’ll leak. Probably not a big deal, as the plugin’s getting unloaded at that point anyway, but personally, I’d suggest that when you create a callout box, you could keep a ScopedPointer to it in your UI class, so it’ll definitely get removed when the UI goes away. ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 13, 2010, 12:34pm UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/7 "2010-08-13T12:34:21Z")
It is allocated on the stack as in the example you have in the documentation. ```auto void mouseDown(const MouseEvent &e) { CallOutBox callOut(*mpColourSelector, *this, NULL); callOut.runModalLoop(); } ``` ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 13, 2010, 2:36pm UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/8 "2010-08-13T14:36:39Z")
You really, really need to avoid runModalLoop() in a plugin. It’s ok in an app, but if the host chooses to delete your plugin during the runModalLoop() call, then when the method returns, your plugin has gone from memory and the stack unwinding will probably cause a crash. Instead use Component::enterModalState(), and provide a callback if you need to know when it has finished. ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 13, 2010, 3:21pm UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/9 "2010-08-13T15:21:53Z")
Thanks for the info, does that mean that any modal dialog should be avoided including PopupMenu? ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 16, 2010, 8:18am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/10 "2010-08-16T08:18:24Z")
> [@mdsp](#): > > Thanks for the info, does that mean that any modal dialog should be avoided including PopupMenu? If possible, yes. PopupMenu::show() now has a callback parameter that lets you run it without a modal loop. ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 16, 2010, 10:38am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/11 "2010-08-16T10:38:40Z")
Ok thanks that works fine now with CallOutBox. ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 16, 2010, 10:53am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/12 "2010-08-16T10:53:21Z")
One more question in showMenu there is a ScopedPointer to hold the userCallback but if there’s a userCallback the method returns immediately. The userCallback should be deleted at this point no? [code] int PopupMenu::showMenu (const Rectangle& target, const int itemIdThatMustBeVisible, const int minimumWidth, const int maximumNumColumns, const int standardItemHeight, const bool alignToRectangle, Component\* const componentAttachedTo, ModalComponentManager::Callback\* userCallback) { ScopedPointerModalComponentManager::Callback userCallbackDeleter (userCallback); ``` ... if (userCallback != 0) return 0; const int result = callback->component->runModalLoop();[/code] ``` ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 16, 2010, 11:07am UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/13 "2010-08-16T11:07:33Z")
No, the ModalComponentManager takes care of deleting that callback object later on. ---
**Author:** ![mdsp](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mdsp](https://forum.juce.com/u/mdsp)\ **Post date:** [August 16, 2010, 1:00pm UTC](https://forum.juce.com/t/dialogwindow-appears-behind-plug-in-window/5359/14 "2010-08-16T13:00:55Z")
oh, I missed the use of release on ScopedPointer ```auto ```