Re: initializer for NSTextView subclass not being invoked on Nib instantiation
Re: initializer for NSTextView subclass not being invoked on Nib instantiation
- Subject: Re: initializer for NSTextView subclass not being invoked on Nib instantiation
- From: Stuart Malin <email@hidden>
- Date: Tue, 7 Apr 2009 22:36:35 -1000
Great explanation, Kyle. Thanks for taking the effort to provide one
so thorough.
On Apr 7, 2009, at 10:28 PM, Kyle Sluder wrote:
On Wed, Apr 8, 2009 at 4:15 AM, Stuart Malin <email@hidden>
wrote:
Googling this issue has led me to discover that, for NSTextView,
-initWithCoder gets called instead.
Yes, indeed.
I've never run into this before -- that is, my subclassed NSView
objects
have their -initWithFrame: invoked (and NOT -initWithCoder). Is there
something in the documentation that I can look for, for a class,
that would
help me know which way the Nib instantiation functionality will
initialize
(that is, -initWithCode versus designated initializer)?
It's helpful to know what's going on inside IB. When you drag an item
from the library into your Nib, IB instantiates an object of that
class, which is encoded into your Nib at save-time. At runtime, the
framework decodes this object from the nib. This is why
-initWithCoder: is being called; the object has already been
initialized with -initWithFrame: when you dragged it into the
document, now we're just reconstructing it from the archive.
For instances of classes that are *not* in the palette, however, IB
does something different. You typically drag an instance of one of
the class's ancestors into your document -- for views, typically this
is an NSView. But when you switch to the Identity pane of the
Inspector and change the class identity, IB instead remembers to
archive a little note saying "this is not the class you're looking
for. Instead you want this class." instead of the object itself. In
the actual editor interface, IB continues using the instance you
dragged out from the library, as it wouldn't be helpful for that to
vanish. This is why -initWithFrame: is called for custom subclasses
configured via the Identity pane; at runtime, the framework sees the
little note saying "go get an instance of this class instead," and
does so. Since this isn't the instance that was freeze-dried into the
Nib, the framework needs to construct an instance, hence calling the
designated initializer -initWithFrame:. It can then configure all the
properties that were archived in the nib, just like it does for
Library-instantiated objects.
Hope that helps,
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden