Re: [newbie] Handling a preferences window
Re: [newbie] Handling a preferences window
- Subject: Re: [newbie] Handling a preferences window
- From: James DiPalma <email@hidden>
- Date: Mon, 30 Sep 2002 13:06:02 -0400
From: Jeremy Dronfield <email@hidden>
From: James DiPalma <email@hidden>
For non-document windows, NSWindowController has little value beyond
releasing top-level objects when its window is closed. I can do this
release too.
Depends on level of expertise, individual programming practice etc.
Inherently, NSWindowController has quite a bit of built-in value, if
it suits you.
NSWindowController has value as a nib controller and as a data
controller. NSWindowController will load nib files, but is only really
useful when loading nib files with windows in them. So, as a nib
controller, it can't be generally useful, nor does it use a public
technique for releasing top-level objects.
As a file's owner, NSWindowControllers can be used as data controllers,
but this technique is only useful for nib's with windows and can
prevent newbies from learning simple techniques that help them with
other nib files.
An NSObject subclass controlling data is simple, it separates
responsibilities, and can be a less confusing technique than
subclassing NSWindowController (especially in NSDocument applications:
compare rewriting -makeWindowControllers to instantiating an NSObject
subclass).
I prefer using NSWindowController as a window controller and leaving
other responsibilities to other classes.
For newbies at least (especially newbies who need to ask how to open a
window), NSWindowController is pretty useful as a File's Owner class.
For the more experienced, an NSObject subclass may ring your bell.
Why is subclassing NSObject a more experienced technique than
subclassing NSWindowController? That newbie's question can easily be
answered: check "Visible at launch time" in IB"s insector to open a
preferences window. Also, showWindow: is kind of confusing since it is
an action method, but can't be used as an action method.
If you feel comfortable using NSWindowController and it works for
you, then it works for you.
I tend to stick with window controllers because I like the convenience
of - initWithWindowNibName:,
loadNibNamed:owner: and a checkbox is as convenient as
-initWithWindowNibName: and calling showWindow:.
- setShouldCascadeWindows: (surprisingly useful even with non-doc
windows) and
You don't explain why. If you pass NO, nothing changes.
setShouldCascadeWindows:YES, will move your window fully on-screen, but
that typically means far to your screen's upper left corner (and under
a left positioned dock). I don't like this cascade functionality.
-setWindowFrameAutosaveName: (which I find the handiest frame-saver in
the catalogue).
I use InterfaceBuilder's window inspector; it has a textfield labeled
"Auto Save Name". Using setWindowFrameAutosaveName: requires you to
subclass NSWindowController or put window controller code outside of
your window controller.
I am suggesting a PreferencesController class that has a
-showPreferences action method that simply calls [NSBundle
loadNibNamed:@"Preferences"]; my preference controller is responsible
for knowing a nib name only.
You are suggesting a PreferencesController that with these lines in its
-showPreferences action method:
NSWindowController * windowController;
windowController = [[PreferencesWindowController alloc]
initWithWindowNibNamed:@"Preferences"];
[windowController setWindowFrameAutosaveName:@"Preferences"];
[windowController showWindow:];
Your Preferences controller has to know a nib name, an autsave name,
and an NSWindowController subclass.
I think my suggestion is a more clean design and just as suited to
newbies as it is to more experienced developers.
-jim
_______________________________________________
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.