Mac dual-display arranged bottom-top causes Y mis-position


I am using a DocumentWindow with JUCE 2.0 and I have a dual-display Mac where the second display (non-main, not the one with the Mac menubar) is arranged to be above the first/main display (the one with the Mac menubar). I am positing the window by calling its setBounds(x, y, width, height) method. I am calculating the height of the Mac menubar like so:

and then using this to offset the Y position value to make sure that the window does not appear behind the Mac menubar if I call setBounds with Y as 0 (a JUCE issue covered elsewhere in the forums). This works fine with a single display or multi-display where a secondary display is not positioned above the main display. However, in the situation described above with a secondary display positioned above the main one, then the window gets drawn behind the Mac menubar even when setting Y to 22 (the height of the Mac menubar). When the secondary display is above, you actually have to double this value to 44 in order to get the window to appear aligned precisely at the bottom of the Mac menubar. So in this situation, the bug is that the positioning of the DocumentWindow is happening with an upward offset equal to the height of the Mac menubar.


Any potential workaround or hope for a fix?


Sorry, this one’s been in my in-box, and I will certainly take a look when I get chance!


Thanks Jules!


Hmmm a have come to determine that my original report was a little bit off. The menubar is 22 pixels height and so is the title bar of the window, however the setBounds call is not taking the window’s title bar into account. In other words, if I specify 22 for Y in the setBounds call, JUCE will position the window contents area (minus the title bar) at Y 22 not the actual top of the window, which puts the window’s title bar behind the menubar when calling setBounds with Y of 22. This is using a DocumentWindow with native title bar. I was mistaken thinking that multi monitors had something to do with this issue, it does not.


Ok, so there’s no problem?


No, there is a problem. With a DocumentWindow using native title bar, setBounds calls place the window offset 22 pixels up because the Y value include the window’s title bar in its placement. So setting Y as 22 in a setBounds call will result in your window’s title bar being entirely underneath the Mac menubar rather than all of the window being directly beneath the menubar (which itself is also 22 pixels high).


Also another related issue is if I am trying to restore a previous window location with a negative Y value (which is the case when locating on a secondary display that is positioned above the main display, as described in the original recipe) and then I reposition that monitor while my application is not running so that the secondary monitor is now positioned to the right side of the main display, then try to restore the saved negative Y value (e.g. -1000) with a setBounds call, JUCE will immediately reposition the window’s Y location to -10. It makes sense to note the no longer available position due to multiple display repositioning and automatically move the window into view, however the -10 position makes no sense and again leaves the window’s title bar obscured under the Mac menubar. It would need to be repositioned to at least Y of 44 (Mac menubar + window title bar heights) to be a safe repositioning.


Well IIRC the setBounds call refers to the position of the content of the window, not the whole thing including its frame. There’s a ComponentPeer::getFrameSize (or something like that) to get the border if you need to handle that.

But I will have a play around with this and see what’s going on.


Thanks for explaining, Jules. Positioning based on content region rather than full window region definitely explains the 22-pixel offset problem. Which just leaves the -10 repositioning issue, not sure what is happening with that (though I do have my code working better now calculating window title bar height, thank you again).