The documentation for awakeFromNib is correct. Are you sure these
events are occurring in the order you think they are? If the interface
isn't already loaded, awakeFromNib should be called from within the
call to 'window' from 'test:'
I would expect the order of the log message to be something like
textField=(null)
nib loaded.
window loaded.
textField= <NSTextField: 0x12345678>
If this isn't the case, then perhaps there are two NIBs being loaded,
and awakeFromNib is being called twice, once for each NIB.
Hope that helps -
Jon Hess
On May 21, 2008, at 11:35 AM, Vijay Malhan wrote:
Yes you are right. If we see this as an optimization enhancement, it
completely make sense to have things work like this. But my point is
that this behavior is not in-sync with the Leopard framework
documentation (XCode 3.0) and Tiger implementation. Following is
extract from the Mac OS X 10.5 SDK reference for awakeFromNib method.
- (void)awakeFromNib
Discussion
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 anawakeFromNib message, it is guaranteed to
have all its outlet instance variables set.
Now with this new behavior, developer will not know, where exactly
it should expect it's UI element to be loaded for sure? And this
will also break the code written in Tiger, when run on Leopard. So
for now, it's a bug according to me.
- Vijay
On 21-May-08, at 11:14 PM, Torsten Curdt wrote:
...actually with this new lazy loading feature code like this
- (IBAction) showPreferences:(id)sender
{
if (!preferencesController) {
preferencesController = [[PreferencesController alloc] init];
}
[preferencesController showWindow:self];
}
could probably just go away and become
- (IBAction) showPreferences:(id)sender
{
[preferencesController showWindow:self];
}
with the alloc in the parent's init method.
...or am I mistaken? Or is that a bug?
cheers
--
Torsten
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/vijay.malhan%40gmail.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/jhess%40apple.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
