restoreWindowStateFromString() bug

My app restores its window state using restoreWindowStateFromString()

  • First bug (?):

When the x position is less than 0, and i open the app again the x will be set to 0. Maybe this is wanted though, so let’s skip this one.

  • Second bug (annoying one):

When the y pos of the window is just under the OS X menu bar, next time when I restart my app, it will be at screen position y=0, so the menu bar is covering up my app.

Well it does clamp the position, in case the screen res has changed since the last time you ran your app, so the first thing is wanted. The other thing sounds like a bug though - I’ll take a look at that…

Screen resolution did not change. Just ran the application again, …
I can’t find out anything because XCode just refuses to stop at breakpoints in my project, I don’t know why.

I avoided restoreWindowFromString() by storing the bounds in my own code, it solved many problems. But still when the y position is directly under the OS X menu bar, this will make the window jump to screen y=0. So something goes wrong after setting the bounds of the ResizableWindow and the problem is not in restoreWindowFromString() itself…

I can’t understand that this bug hasn’t been reported before.

That does sound a bit strange. Does your window use a native titlebar?

Nope, a JUCE titlebar

I found out something else, which has without any doubt to do with the problem:

On OS X, when the Title Bar of the DocumentWindow is a JUCE Title Bar, then the top left position of the DocumentWindow is the upper left corner pixel of the DocumentWindow (relative to screen x=0, y=0).

However, when the DocumentWindow uses a native OS X Title Bar, the top left position of the DocumentWindow is the upper left pixel of its Content Component (relative to screen x=0, y=0) !!!

With the native title bar, there is no problem with restoring the window to its position. In the case of the native title bar, y of DocumentWindow will at least be 44, whereas using the JUCE title bar, y of DocumentWindow will be at least 22.

other bugs:

  • centreWithSize() doesn’t work correctly with a native OS X title bar DocumentWindow, one has to add the menu bar height (=22) to the Y position after calling centreWithSize().

  • setFullScreen(true) doesn’t work correctly with a native OS X title bar DocumentWindow. Again one would had to add 22 to its y.

This is ofcourse all because of the aforementioned problem with the top left position.

Please, no more OSX bugs just yet! There’s no point in me looking into any of this, because I’ve already scrapped all the carbon code!

I am always very reluctant to use the latest SVN tip. Is that bug now gone with the new Cocoa code?
How long do you reckon it will take for the Carbon->Cocoa transition to be completely finished?

I’ve written all the cocoa stuff apart from the AU wrapper… As soon as that’s there, I’ll check it all in and let people loose on it!