Re: Bypassing Interface Builder
Re: Bypassing Interface Builder
- Subject: Re: Bypassing Interface Builder
- From: "I. Savant" <email@hidden>
- Date: Wed, 14 May 2008 21:07:08 -0400
On May 14, 2008, at 8:51 PM, I. Savant wrote:
And if I want to refer by name to that instance in my code, what is
the name of the instance?
Nothing. That is, not until you add an IBOutlet in whatever class
you want to connect to that instance.
Let me clarify this a bit further. An instance that's unarchived
from a loaded nib can easily have no reference to it at all from your
own code. It's analogous to having a program that does this at launch:
[[NSObject alloc] init];
Note there's no pointer like this:
NSObject * myObject = [[NSObject alloc] init];
If the first (no-pointer) line is run at application launch, you've
got an NSObject instance floating around somewhere you can no longer
reach. Other objects may have a reference to this (such as this case):
[[[NSObject alloc] init] autorelease];
Your own code has no reference to this object and it's just set
adrift immediately upon creation. Other objects (such as an
NSAutoreleasePool instance) have can have references to it. Perhaps
some other object to which you have a reference may reference it, but
if not, you've lost the ability talk directly to it.
Of course the use of mechanisms such as KVO, message centers and
such makes such a scenario fairly common. If I have a basic array
controller that works perfectly in its default configuration, why
should I need an outlet with which to send it messages? If, however, I
need to 'kick' it by sending it a -fetch: message from within my code,
an outlet would sure make that easier ...
--
I.S.
_______________________________________________
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