In a certain sequence of normal client calls, a sequence of Juce-only code causes a ResizableWindow to “dance” on screen:
Client code:
ResizableWindow* w = createMyWindow (); // visible but not on desktop
w->addToDesktop ();
Juce call sequence:
- Component::addToDesktop
styleWanted == 25 (16 + 8 + 1)
The window appears on screen before internalHierarchyChanged() with a native title bar and no small icon - Component::internalHierarchyChanged
- DocumentWindow::parentHierarchyChanged
- DocumentWindow::lookAndFeelChanged
- ResizableWindow::lookAndFeelChanged
- Component::addToDesktop
During this call the window is removed, and reappears with a native title bar and a small icon.
This causes the “dancing” effect
There is a workaround, which is to create the window as non-visible. But I consider it a bug that there is a code-path through Juce that causes the window to appear, disappear, then reappear, from a single client call into the Juce library.
There is nothing fancy about my window, its a simple modal dialog. Here’s the constructor:
SettingsWindow::SettingsWindow (CoreView& coreView)
: DialogWindow (TRANS("Settings"),
Colour(192,192,192),
true,
false)
, CoreComponent (coreView)
{
SettingsPanel* contentComp = new SettingsPanel (coreView);
setOpaque (true);
setResizable (true, false);
setDropShadowEnabled (false);
setUsingNativeTitleBar (true);
// must happen AFTER setUsingNativeTitleBar()
//Component::addToDesktop (getDesktopWindowStyleFlags());
//addToDesktop ();
// must happen after addToDesktop()
setContentOwned (contentComp, true);
centreWithSize (getWidth(), getHeight());
//setVisible (true);
enterModalState ();
}
This did not happen in the latest pre-modules tip.