Repost because of size restriction: Re: Hiding superclass methods
Repost because of size restriction: Re: Hiding superclass methods
- Subject: Repost because of size restriction: Re: Hiding superclass methods
- From: "Erik M. Buck" <email@hidden>
- Date: Fri, 10 May 2002 15:31:49 -0500
Read
http://www.stepwise.com/Articles/Technical/FreezeDriedObjects.html
Objects are initialized when they are instantiated in IB or copied from a
palette into a nib file. They are then archived into a nib file. When an
application loads a nib file, it unarchives the objects in the nib file.
The -initWithCoder: method of each object that is unarchived is
alled. -init and -initWithFrame: and other initializers
besides -initWithCoder: are NOT called when an object is unarchived. (*There
is a special exception for custom views in IB)
You can do initialization in initWithCoder:, but not all outlets will have
been connected then. Therefore -awakeFromNib is available to finish
initialization after all objects have been unarchived and all of the outlets
have been set .
There is no magic.
Everything is well documented.
Read about NSCoder and NSArchiver and NSUnarchiver.
* When a custom view is used in IB, IB allocates and initializes a place
holder object. When the place holder object is unarchived, it allocates and
initializes an object using the designated initializer, -initWithFrame:.
The existence of the custom view object on an IB palette is a convenience
that lets you design interfaces with classes that IB does not know anything
about. If you don't want to worry about this special case, don't use custom
view. There are alternatives including creating new IB palettes for custom
objects.
PS I did not have to reverse engineer the frameworks or perform timing
studies or any other nonsense to find this information. It is clearly
documented.
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/ApplicationKit/Ob
jC_classic/Protocols/NSNibAwaking.html
<Quote>
Prepares the receiver for service after it has been loaded from an Interface
Builder archive, or nib file. An awakeFromNib message is sent to each object
loaded from the archive, but only if it can respond to the message, and only
after all the objects in the archive have been loaded and initialized. When
an object receives an awakeFromNib message, it's guaranteed to have all its
outlet instance variables set.
Note: This method is also sent during Interface Builder's test mode to
objects instantiated from loaded palettes, which include executable code for
the objects. It isn't sent to objects defined solely by using the Classes
display of the nib file window in Interface Builder.
When an Interface Builder archive is loaded into an application, each custom
object from the archive is first initialized with an initWithCoder: message.
It's then more specifically initialized with the properties that it was
configured with using Interface Builder. This part of the initialization
process uses any setVariable: methods that are available (where variable is
the name of an instance variable whose value was set in Interface Builder).
If a setVariable: method doesn't exist, the instance variable is searched
for. If it exists, the instance variable is directly set. If the instance
variable doesn't exist, initialization does not occur. Finally, after all
the objects are fully initialized, each receives an awakeFromNib message.
The order in which objects are loaded from the archive is not guaranteed.
Therefore, it's possible for a setVariable: message to be sent to an object
before its companion objects have been unarchived. For this reason,
setVariable: methods should not send messages to other objects in the
archive. However, messages to other objects can safely be sent from within
awakeFromNib-by which time it's assured that all the objects are unarchived
and initialized (though not necessarily awakened, of course).
Typically, awakeFromNib is implemented for classes whose instances are used
as the owners of a loaded nib file (shown as "File's Owner" in Interface
Builder). Such a class has the express purpose of connecting the loaded
objects with objects in the application, and can thereafter be disposed of,
or remain in the capacity of a controller or coordinator for the loaded
objects. For example, suppose that a nib file contains two custom views that
must be positioned relative to each other at run time. Trying to position
them when either one of the views is initialized (in initWithCoder: or a
setVariable: method) might fail, since the other views might not be
unarchived and initialized yet. However, it can be done in the nib file
owner's awakeFromNib method (firstView and secondView are outlets of the
file's owner):
- (void)awakeFromNib {
NSRect viewFrame;
if ([[self superclass]
instancesRespondToSelector:@selector(awakeFromNib)]) {
[super awakeFromNib];
}
viewFrame = [firstView frame];
viewFrame.origin.x += viewFrame.size.width;
[secondView setFrame:viewFrame];
return;
}
Note the testing of the superclass before invoking its implementation of
awakeFromNib. The Application Kit declares a prototype for this method, but
doesn't implement it. Because there's no default implementation of
awakeFromNib, be sure to invoke it only when the object does in fact
respond.
See Also: + loadNibNamed:owner: (NSBundle Additions), - awakeAfterUsingCoder
(NSObject class), - initWithCoder: (NSCoding protocol), + initialize
(NSObject class)
<END Quote>
http://www.oreilly.com/catalog/learncocoa/apple/ch10.html
http://www.channelu.com/NeXT/NeXTStep/3.3/nd/DevTools/NewInterfaceBuilder/04
_CreatingClass.htmld/
http://216.239.35.100/search?q=cache:tr9z8QQSHUIC:www.gnu.org/software/gnust
ep/resources/OpenStepSpec.ps.gz+initWithCoder+Interface+Builder+awakeFromNib
&hl=en
http://216.239.35.100/search?q=cache:tr9z8QQSHUIC:www.gnu.org/software/gnust
ep/resources/OpenStepSpec.ps.gz+initWithCoder+Interface+Builder+awakeFromNib
&hl=en
http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_c
lassic/Classes/NSObject.html
_______________________________________________
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.