Re: NSWindow not restoring location
Re: NSWindow not restoring location
- Subject: Re: NSWindow not restoring location
- From: Brock Brandenberg <email@hidden>
- Date: Thu, 11 Jul 2002 14:05:16 -0500
Hi Pierre.
>
> So, the solution is to call [NSWindowController setShouldCascadeWindows:NO]
>
> in your NSWindowController subclass to turn this behavior off for the
>
> controller of any singleton window you are trying to position. After that,
>
> it should explicitly restore the position no matter where it was previously
>
> located. Just make sure to set your autosave name properly and call [window
>
> setFrameUsingName:] in [NSWindowController windowDidLoad].
>
>
That seems to be an interesting solution, but how would do you do that if
>
you're building a non-document-based Cocoa application (i.e. Without any
>
NSWindowController)? I have this window positioning problem that appears
>
sometimes in my Cocoa apps.
The simplest way is to create an app delegate in your main nib file, connect
your window to its IBOutlet and access the window's windowController from
there in applicationDidFinishLaunching:.
@interface MyAppDelegate : NSObject
{
IBOutlet NSWindow *myWindow;
}
@end
@implementation MyAppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)notification
{
[[myWindow windowController] setShouldCascadeWindows:NO];
}
@end
I'm not sure that this solution is right for cases other than the one that
I've described, though, because I still see other behaviors that I can't
explain yet. For instance, I can create a new Cocoa app project and do
nothing other than set the autosave name for the window, build and run it,
and the app will properly save the window location with no additional code.
Drag the window, quit, restart and the window will be in the last position.
In these cases, there is a proper domain plist file in the
~/Library/Preferences folder where the userDefaults are being saved. Other
times, I can create a new Cocoa app project, write some code, go back to the
nib and set the autosave name and nothing works properly. In these
instances, I can't find a plist file in the proper domain where the position
could be saved, which partly explains it. NSUserDefaults must be caching the
info somewhere, but not properly restoring it.
Anyway, when seeing this problem in my app with a NSWindowController
subclass, I broke on windowDidMove: in GDB and looked at the stack trace. In
my case, it had a cascading window method being called when there was no
need for it. This method is what was repositioning the window outside the
visibleFrame and causing it to be repositioned again in a default location.
If anyone can help put these clues together, I'd love to clarify this issue
once and for all.
Bye.
Brock Brandenberg
----- industrial design @ www.bergdesign.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.