Since moving to Juce 7, my alert window and ThreadWithProgressWindow are not centred anymore with the associatedComponent.
Is this a known regression ?
mpAlertWindow->centreAroundComponent(associatedComponent, mpAlertWindow->getWidth(), mpAlertWindow->getHeight());
afterwards does the trick but it’s supposed to be done already, no ?
What OS do you encounter this problem on?
What call do you use to display the
AlertWindow::showAsync (MessageBoxOptions().withAssociatedComponent()) and they seemed to work correctly on MacOS and Windows 10.
.createAlertWindow("title", juce::String(), "Cancel",
juce::AlertWindow::NoIcon, 1, associatedComponent))
mpAlertWindow->enterModalState(true, new AsyncLoadingCanceledCallback(***this**));
Sadly I haven’t been able to reproduce this yet, even with your approach.
I’ve tested this on MacOS 12.5 and the latest JUCE develop version.
don’t bother much. I’ll let my quick fix. no biggie
I noticed something similar the other day and just took another look. I also now noticed I have one AlertWindow where it centers correctly, and one where it doesn’t.
The one that centers correctly has only one button, while the one that doesn’t has two.
Here’s how I call it:
As soon as I add another
.withButton(), the alert doesn’t appear at the center anymore.
There is definitely something off with Juce7 regarding AlertWindows and reference Components. Not only the placement but also the scaling on hdpi monitors didn’t work correctly after switching from juce6 to juce7. I didn’t have the time to look into it more closely and had to roll back to juce6. Would be great if this can be resolved soon.
This one has been driving me crazy; I was having trouble reproducing it. Thanks for the tip about adding the second button; that did the trick.
For me, it happens if the AlertWindow has two buttons and the associated component is on the right side of the screen.
I think the problem is in TopLevelWindow::centreAroundComponent; specifically, this line:
auto parentArea = getLocalArea (nullptr, c->getParentMonitorArea());
I think this should instead be just:
auto parentArea = c->getParentMonitorArea();
I can post a simple, reproducible example if need be.
I have to correct my last comment and scaling and positioning seem to be two unrelated issues. the switch to juce7 only introduced the position issue.
I already mentioned this in a thread a while back and tracked it back to this commit:
Before this everything works and after it the positioning has unexpected results quite often.
Good find! Seems to have something to do with that commit.
Some more observations:
- One-button AlertWindow is always positioned correctly
- Two-button AlertWindow does weird things depending on the position of the plugin window
- Positioned correctly when it’s in the top-left quarter of the main screen
- When it’s in the bottom-left quarter of the main screen, vertical position seems mirrored vertically (it’s positioned in the top-left quarter)
- Similarly, when it’s in the top-right quarter, horizontal position seems mirrored horizontally (it’s in the top-left quarter)
- Guess what happens in the bottom-right quarter: AlertWindow goes to the top right
This is only when it’s on the main screen. When the plugin is on a second screen, the AlertWindow goes somewhere on the main one.
When I revert the mentioned commit, everything works fine with my normal UI size. However, with zoomed UI (e.g. 150%), even the one-button alert starts to act weirdly (which is probably what the commit was supposed to fix). Especially when the plugin is on a second screen. Putting the commit back in fixes this only for the one-button version, but the two-button one still acts weird.
Thank you all for the detailed explanation. A fix is now out on