NSScreen giving me nonsensical coordinates

[XnavxeMiyyep]

NSRect frameRect;

....

for(int i = 0; i < scns; i ++){

frameRect = [[[NSScreen screens] objectAtIndex:i] frame];
NSLog(@"Checking screen %i: %f %f %f %f",i,frameRect.origin.x,frameRect.origin.y,frameRect.origin.x+frameRect.size.width,frameRect.origin.y+ frameRect.size.height);

...

}


Checking screen 0: 0.000000 0.000000 1600.000000 1200.000000

...

Checking screen 1: -1680.000000 150.000000 0.000000 1200.000000

The coordinates assume that my screens are aligned at the bottom, which is not the case; they are aligned at the top, so screen 1 should be -1680, 0, 0, 1050.

I suppose it wouldn't be a problem, except that my program interacts with AppleScript, which actually gets the proper coordinates. I can't just put a 150 pixel vertical offset (which is, of course, the difference in heights of the monitors), because I want to ultimately produce a real program. :(

Am I missing something? Is there an alternative to NSScreen? I'm so close to finishing this project, but I can't make any sense out of this. :confused:

[kainjow]

0 in the y-axis in Cocoa/Quartz is the bottom of the screen, so it makes sense to me. What is the AppleScript doing?

[Sayer]

Quartz assumes the origin is in the lower left corner.

Carbon will still assume the origin is in the top left corner, which explains the AppleScript result.

So either work with what Quartz gives you or do some small amount of math on the results to massage them the way you think they should be.

[XnavxeMiyyep]

Ok, thanks guys.:) That also explains why I thought the visible frame assumed the menubar was at the bottom.

I'm working on a utility called Gridlock (http://dotdotcomorg.net/Mac/gridlock.php) that allows you to move and resize windows based on coordinates on a hypothetical grid, and wanted to make it work on multiple screens.