On 12.08.2009, at 22:59, Dave Keck wrote:
I've found that there's never any reason not to reset a variable after
releasing it. IMO it's just good practice.
I agree with that point. You may want to declare a macro like this:
#define INVALIDATE_REFERENCE(obj) ([(obj) autorelease], (obj) = nil)
Quincey –
In practice, the delegate is often -- independently of its role as
delegate -- the *owner* of the referencing object (e.g. a window
controller that is a delegate of a table view loaded from a nib file
is the owner of the nib file's contents, including, directly or
indirectly, th
In fact, relinquishing ownership of the connection during this
method is simply a bug. If you're its owner, you're responsible for
preventing it from being deallocated while it's still alive -- and
it's still alive.
In this case, you're pretty sure that autoreleasing it keeps it from
bein
2. [somewhat important] It instills a false sense of security, but
implying that extending the object lifetime to the next pool drain
is always a sufficient lifetime extension. It isn't, not necessarily.
Yes, I think that’s the point the we’ve been paying most attention to.
3. [somewhat more
On 25.08.2009, at 12:30, Brian Bruinewoud wrote:
I have a simple view that contains a UITextField and a UIButton. The
user will most often want to type text and ignore the button. Is
there some way I can make the keyboard appear immediately that view
is shown? I can't find anything in IB an
___
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
