Re: Hiding superclass methods
Re: Hiding superclass methods
- Subject: Re: Hiding superclass methods
- From: Brock Brandenberg <email@hidden>
- Date: Fri, 10 May 2002 16:47:31 -0500
Hi Erik & Glen.
Since I'd be duplicating the same info, I'm just concatenating my
responses together. Hope you don't mind.
Erik, thanks for the lengthy excerpt from NSNibAwaking, but it's your
first paragraph and the last of Glen's comments that finally and best
ties the concepts together. I've read the "FreezeDriedObjects" article
before, but it didn't tie its analogies to the Cocoa methods used to
encode and archive, so the connection never really sank in to my brain.
I haven't personally read through any section in the Apple docs either,
that really made it clear that IB creates a nib by encoding the objects
that the user instantiates in IB. Seeing it as nothing other than an
encoded and archived stream of objects that were first instantiated by
IB makes it much more clear. So, bringing a nib file to life is
basically like me bringing an encoded and archived stream of objects to
life that I might have created by writing custom data out to a file. I
assume this is a better understanding?
I have always read the word "archive" as something other than the basic
Cocoa encoding and archiving process. I think everything that I have
read so far in Apple's docs has spent too much time on details and not
enough describing the fundamental flow. If my understanding is now
correct, I would describe it as a a forked path with two starting points
and one ending point. One starting point represents archived object data
in a file (nib or custom user data), while the other starting point
represents a new object being declared and initialized at runtime. The
archived data path must go through a series of operations where the
archived stream of data is read in, unarchived and decoded requiring
coder initializers (or the underhanded key/value coding methods that
Glen refers to) to process the data. The other path goes through
designated initalizers like init: or initWithFrame: instead. Along each
path, there are a number of "progress reports" like windowWillLoad:,
windowDidLoad: or awakeFromNib: that let the developer know what stage
of initialization the object is at. Knowing what is and what is not
initialized at each stage is they key to knowing what you can do with an
object and when you can do it.
So, having personally implemented encoding and archiving methods,
inserting the terms "encoding and decoding" into the nib file discussion
makes the concept clearer.
But, again, the statement "all its elements are already initialized" is
a pretty clear statement; if the objects are already initialized,
there's no need to call the initializer methods.
True. My confusion was with how the initialization was happening. Did
Cocoa use the key/value coding to secretly stuff values into memory, did
the initWithCoder: method get called, or did the initWithFrame: method
called? In essence, I wasn't sure what branch of the forked path I was
on.
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".
Do you know this as fact, from direct experience, or is it simply "how
can they *not* be called?" I've included NSLog calls in initWithFrame:
in views I've loaded from a nib file, and the calls were not executed,
indicating that initWithFrame: wasn't executed, either.
So far, all of my custom views have behaved as I have expected. When I
instantiate a custom view in the content view of a window or in one of
it's subviews (like an NSTabView), my initWithFrame:, the designated
initializer is being called reliably. Now, I can certainly see (now that
the education is sinking in) that if I were to encode and archive any of
these custom views to a file, then open and unarchive the file, this
statement would not be true. I would have to rely on my initWithCoder:
methods because the designated initializers would not be called on that
path of initialization. Again though, all my views in the main nib file
are getting their designated initializers called.
So far, I have only used custom views in my main windows and default
objects from IB in floating palettes. I need the custom views to do
glyph and polygon drawing, and my inspector palettes have used nothing
other than pop-up menus, text fields and other standard controls (no
custom views even) to display object properties. I haven't created any
palettes for IB yet, but from these discussions, I assume that I could
create custom palettes for IB that gives IB the ability to instantiate
and encode them in my nib file. That way, if I needed to, I could "play"
with them using the "test interface" functionality inside IB, and I'd
have to initialize them in awakeFromNib: after the nib file is loaded.
Sound right?
Thanks,
Brock
P.S. Erik, still waiting for the new book :)
----- 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.