Re: Hiding superclass methods
Re: Hiding superclass methods
- Subject: Re: Hiding superclass methods
- From: Brock Brandenberg <email@hidden>
- Date: Fri, 10 May 2002 14:23:26 -0500
Hi Glen.
I think we've run into another area in the Apple docs that isn't
clarified very well. I feel like the reference you mentioned:
/Developer/Documentation/Cocoa/TasksAndConcepts/ProgrammingTopics/LoadingResources/
Concepts/NibFileLoaded.html
... paints too broad of a stroke with its wording. I think what's
confusing is that opening, loading and initialization constitute a
multi-step process and we may be interpreting some of the wording in the
docs too broadly. Bill Cheeseman will probably say that the
documentation is exactly correct (I've seen him point this out
before :), but it doesn't have enough detail or enough examples to put
it all in perspective. Once you know how it all works, the docs may be
perfectly clear. Hindsight's always 20-20.
Now, I have to make sure that I don't step out of my bounds of
understanding here because I haven't loaded any nib files using the
NSBundle methods. I've only loaded ones from a custom window controller
using initWithWindowNibName: to load the nib and windowDidLoad: to start
using the window after loading.
In the reference, Apple says:
"If you need to initialize an object after its nib file has been loaded,
create an awakeFromNib method for the object. It's called after all nib
file's objects have been loaded and all the connections have been set
up."
This statement is correct, but it leaves something out. When the file is
loaded, the designated initializers must be called for the objects
otherwise the objects couldn't be instantiated. However, like it says,
you can't fully initialize your custom objects until awakeFromNib: is
called because no IBOutlets are valid until this time. But the reference
goes on to say:
"Note that the init and initWithFrame: methods are never called when a
nib file is opened. As you create a nib file, Interface Builder
automatically initializes its elements. When you later load that nib
file, all its elements are already initialized."
I think this is where my confusion starts, and the critical word here is
"opened." I don't know the exact chronology, but I would suspect that
"opening" only brings the serial stream of data into memory, but does
not instantiate any of what it represents. "Loading" is what decodes and
instantiates any objects. Am I correct? Now, I know that any custom
subclasses that I instantiate by placing them in a window's content view
(in my main nib file) get their initWithFrame: method called when that
nib file is "loaded". I feel like this is an absolutely necessary part
of the initialization process since Cocoa can't just ignore
initializers. An object has to have an initializer called. If I need to
do additional initialization beyond what is possible in initWithFrame:,
though, I would have to implement awakeFromNib: also. So, the init: and
initWithFrame: methods are called after opening and during the loading
process. In the case of the custom window controller, you know when
loading is about to start (windowWillLoad:) and when it has finished
(windowDidLoad:), between which your objects had to have their
initializers called. Anyone want to reassure me that this is right?
I'd love to know what kind of experimentation you've done that doesn't
call the init methods because I don't want to ever get caught by this. I
feel like I had a grasp on the order of initialization, and now there's
a cloud over my head :) Chronologies of events is one of those areas
that I gripe about in the Apple documentation. Aaron Hillegass touches
on the chronology of NSApplication starting up, but it would be great to
have them for a number of other objects and/or tasks like loading nib
files. Does anyone want to put some joint effort into creating something
like this?
Thanks,
Brock Brandenberg
----- industrial design @ 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.