Re: Problem of positioning a full screen window
Re: Problem of positioning a full screen window
- Subject: Re: Problem of positioning a full screen window
- From: Matt Neuburg <email@hidden>
- Date: Wed, 6 Feb 2002 13:23:25 -0800
On Tue, 5 Feb 2002 09:19:54 -0700, email@hidden said:
>
I also design a small window, and resize it use
>
[self setFrame:[[self screen] frame] display:YES];
>
it works if the window is in MainMenu.nib, and has the same problem when
>
it is put in another nib file. Even if I set the origin of the window to
>
(-20, -10), the window's origin point didn't change.
>
I wonder if I do something wrong or it's a bug?
Let's recall that an NSWindowController by default cascades its window by
calling cascadeTopLeftFromPoint:, and that when windows are positioned they
call constrainFrameRect:toScreen:. These facts could be the cause of your
difficulty.
The rest of this note is long and describes an experiment.
I created a very small project consisting of two nib files. Each has one
window. The windows are identical except the titles, so that we can
distinguish them. The main nib file has an instance, MyObject, which is an
NSObject, with an outlet "window" pointing at the window. The second nib
file is called "OtherNib" and is owned by an NSWindowController subclass
MyOtherObject, whose "window" outlet is pointing at the window in that nib
file.
MyOtherObject has just one method, whose job is to show its window at 0,0:
- (void) showYourWindow {
[self showWindow: self]; // call this "line 1"
[[self window] setFrameTopLeftPoint: NSMakePoint(0,0)];
[[self window] makeKeyAndOrderFront: self];
}
MyObject has just one method, awakeFromNib; it shows its window at 0,0 and
instantiates MyOtherObject and calls its method:
- (void) awakeFromNib {
MyOtherObject* wc =
[[MyOtherObject alloc] initWithWindowNibName: @"OtherNib"];
// call this "position 2"
[self->window setFrameTopLeftPoint: NSMakePoint(0,0)];
[self->window makeKeyAndOrderFront: self];
[wc showYourWindow]; // call this "line 3"
}
I have two monitors.
RESULT 1: Run the program. The two windows appear on two different monitors.
RESULT 2: Move line 3 to position 2. Run the program. The two windows
appear in the same location on monitor 2.
RESULT 3: Comment out line 1. Run the program. The two windows appear in
the same location on monitor 1.
Now, intuitively one finds this confusing. On the other hand the docs do
warn that constrainFrameRect:toScreen: is being called behind the scenes.
The question might then be simply how this method decides what screen to
use. To see if we're on the right track, I reverted the code to its
original state (so that I get Result 1 again), and then created an NSWindow
subclass that overrides constrainFrameRect:toScreen:, and changed the
window in each nib to an instance of that subclass:
- (NSRect)constrainFrameRect:(NSRect)frameRect toScreen:(NSScreen *)aScreen {
NSLog (@"Called for %@", [self title]);
NSLog (NSStringFromRect(frameRect));
return frameRect;
}
RESULT 4: Run the program. The window in the main nib file now is
positioned with its top left at 0,0 (under the menu bar) as requested. But
the window in the secondary nib file is not; it's still on the other
monitor (and its constrainFrameRect was called 6 times!).
RESULT 5: Comment out line 1 again. Run the program. Both windows now
appear with their top left at 0,0 and constrainFrameRect was called just
twice for the second window - once when it cascades at loading time, and
then when it is shown.
Result 5 is the result we were trying to achieve.
The mystery remains of what causes Result 4. It is plainly the wrong
result. Line 1, which we commented out, is the call to showWindow. Why does
this make a difference? I think it's because now when we position the
window we aren't repositioning. When we do reposition, we get a lot of
calls to constrainFrameRect, more than seems reasonable, and I see that the
incorrect jump of the window takes place just after calling _setFrameCommon
which calls _oldPlaceWindow which calls constrainFrameRect. I can't see
into those routines, but I wonder whether there's a bug in there somewhere.
m.
m.
--
matt neuburg, phd = email@hidden,
http://www.tidbits.com/matt
pantes gar anthropoi tou eidenai oregontai phusei
Subscribe to TidBITS! It's free and smart.
http://www.tidbits.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.