Under certain rather complex circumstances (which I'll describe in a moment),
the window created by initWithContentRect:styleMask:backing:defer:screen:
doesn't appear where it should in my program. But the demo program WhackedTV,
running in identical context, and with a cut-and-pasted copy of _my_
initWithContentRect call, does what it should. Apparently, window placement is
subject to some condition I'm not expecting. Anybody got a hint?
The complex circumstances: placement is only weird if
- the desired location is on a secondary screen (one without the menu bar)
- and outside a rectangle on that screen that's almost, but not quite, the
same size as the primary
If I move the desired location a couple pixels into the magic rectangle, the
window gets placed as expected; a couple pixels out, and it doesn't.
In both programs, my actual window creation code is:
NSWindow *hiddenWindow = [[NSWindow alloc]
initWithContentRect:NSMakeRect( 928, 1390,
640, 480 )
styleMask: NSTitledWindowMask |
NSClosableWindowMask
backing:NSBackingStoreNonretained
defer:NO
screen:screen];
My screen configuration (users with other configurations have reported similar
misbehavior):
The primary screen is the built-in LCD of a MacBook Pro, running at 1440x900.
The secondary screen is an Apple 30" Cinema HD, 2560x2600.
According to the "Arrangement" tab of the Displays prefs panel, the primary
screen is centered below the secondary.
With this arrangement, the visibleFrame of the secondary screen is:
- origin.x: -593
- origin.y: 900
- size.width: 2560
- size.height: 1600
As I understand it, the content rectangle is "in screen coordinates," so the
requested origin of (928, 1390) is near the horizontal middle of the secondary
screen (928 from the left, out of a possible 2560), and fairly near the top
(1390 of a possible 1600). And, indeed, that's where WhackedTV puts its window,
after I've whacked it to use the window-creation code above.
But my app puts its window elsewhere. For this content rectangle, the window
comes up at (335, 1458) ([hiddenWindow frame].origin). These dimensions seem to
be relative to the origin of the primary screen, or converting to the displayed
screen's dimensions:
- x: (335 -(-593)) == 928: correct
- y: (1458 -(900)) == 558: incorrect, expected 1390
... and, indeed, the window actually appears "near the horizontal center of the
secondary screen," and yet in its lower third, not its upper third.
Other positions give larger or smaller errors, and some positions and screen
arrangements give errors in the horizontal direction instead of, or in addition
to, the vertical error described here.
I've also discovered cases where things make even less sense. For example, if I
create the window at (928, 887), it appears where I expect it, as nearly as I
can tell by eye-balling the coordinates, but the reported [hiddenWindow
frame].origin is (928, 55) in absolute terms. There's a band of 20 pixels or so
with this completely disconnected behavior; below that, both display and
reported frame are as expected.
-==-
Jack Repenning
jackrepenn...@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
