Re: cell-based NSTableView, NSArrayController and first responder

> On 12 Jul 2017, at 14:32, Ken Thomases wrote: > > On Jul 12, 2017, at 4:52 AM, Martin Hewitson > wrote: >> >> I have a new bug in an application which I believe has only appeared in >> 10.12. >> >> I have a cell-based NSTableView backed

Re: Who owns a child view controller?

> On Jul 12, 2017, at 2:03 PM, Greg Parker wrote: > > The benefit of the autoreleasing convention comes when you can return an > unretained value without a retain/autorelease pair, because you "know" that > the object will live long enough for the callee to use it. This

Re: Who owns a child view controller?

> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes > wrote: > > I’m trying to understand memory management so I can avoid retain cycles and > other issues. That’s fine. But using a weak reference to try to detect when an object gets dealloced is fraught with peril,

Re: Who owns a child view controller?

On Jul 12, 2017, at 16:19 , Greg Parker wrote: > > "Unowned" means something else in Swift. I suppose. I guess I’ve internalized “unowned” to mean “unretained but crashes tidily” in Swift, but “unretained and crashes as messily as possible” in Obj-C. :) Plus, Swift has

Re: Who owns a child view controller?

> On Jul 12, 2017, at 4:15 PM, Quincey Morris > wrote: > >> On Jul 12, 2017, at 14:57 , Jeremy Hughes >> wrote: >> >> I’m trying to understand memory management so I can avoid retain cycles and >> other issues. > > There’s

Re: Who owns a child view controller?

On Jul 12, 2017, at 14:57 , Jeremy Hughes wrote: > > I’m trying to understand memory management so I can avoid retain cycles and > other issues. There’s nothing wrong with trying to understand. The bet you will (almost always) lose is one involving reasoning about

Re: Who owns a child view controller?

> On 12 Jul 2017, at 23:18, Doug Hill wrote: > > While this discussion has been good at understanding underlying ARC and > manual ref-count issues, my guess as to what's causing these issues is that > you shouldn't just assign nil to the childViewControllers array.

Re: Who owns a child view controller?

> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes > wrote: > >> On 12 Jul 2017, at 22:07, Quincey Morris >> wrote: >> >>> Or there's something else going on under the covers. >> >> Yes, you are correct, betting *against* this

Re: Who owns a child view controller?

> On 12 Jul 2017, at 22:07, Quincey Morris > wrote: > >> Or there's something else going on under the covers. > > Yes, you are correct, betting *against* this assumption is a really, really > terrible idea. Reasoning about the point at which objects

Re: Who owns a child view controller?

Thanks for elucidating! > On 12 Jul 2017, at 22:03, Greg Parker wrote: > > ARC does add an optimization where a cooperating caller and callee can safely > avoid the retain/release pair around the return operation, effectively > transforming that call into the

Re: Who owns a child view controller?

> On Jul 12, 2017, at 1:24 PM, Jens Alfke wrote: > >> On Jul 12, 2017, at 10:38 AM, Charles Srstka > > wrote: >> >> While that’s true, the main reason, as I understand it, that ARC doesn’t >> know enough about the

Re: Who owns a child view controller?

On Jul 12, 2017, at 13:59 , Steve Christensen wrote: > > It's also possible that, as an implementation detail, AppKit isn't > disconnecting the view controller's view from the view hierarchy until it > gets around to doing all the other view processing like redraws. If so then

Re: Who owns a child view controller?

> On Jul 12, 2017, at 11:24 AM, Jens Alfke wrote: > >> On Jul 12, 2017, at 10:38 AM, Charles Srstka >> wrote: >> >> While that’s true, the main reason, as I understand it, that ARC doesn’t >> know enough about the object’s lifetime is that

Re: Who owns a child view controller?

On Jul 12, 2017, at 1:16 PM, Jeremy Hughes wrote: > >> On 12 Jul 2017, at 19:25, Jens Alfke wrote: >> >>> >>> On Jul 12, 2017, at 10:57 AM, Jeremy Hughes >>> wrote: >>> >>> Wouldn’t it be ARC (rather than the

Re: Who owns a child view controller?

> On 12 Jul 2017, at 19:24, Jens Alfke wrote: > >> While that’s true, the main reason, as I understand it, that ARC doesn’t >> know enough about the object’s lifetime is that non-ARC code may be calling >> the method. In an all-ARC world, a method could always just return

Re: Who owns a child view controller?

> On 12 Jul 2017, at 19:25, Jens Alfke wrote: > >> >> On Jul 12, 2017, at 10:57 AM, Jeremy Hughes >> wrote: >> >> Wouldn’t it be ARC (rather than the consumer) that is balancing retains? > > Yes. ARC internally generates calls to -autorelease

Re: Who owns a child view controller?

> On Jul 12, 2017, at 10:57 AM, Jeremy Hughes > wrote: > > Wouldn’t it be ARC (rather than the consumer) that is balancing retains? Yes. ARC internally generates calls to -autorelease (or actually to some C functions in the runtime that invoke autorelease.)

Re: Who owns a child view controller?

> On Jul 12, 2017, at 10:38 AM, Charles Srstka wrote: > > While that’s true, the main reason, as I understand it, that ARC doesn’t know > enough about the object’s lifetime is that non-ARC code may be calling the > method. In an all-ARC world, a method could always

Re: Who owns a child view controller?

I used them in 2012 when dealing with capturing AV input from the front and back cameras on iDevices with ARC code. IIRC, they were in the Apple sample code. > On Jul 12, 2017, at 11:54 AM, Jeremy Hughes > wrote: > >> On 12 Jul 2017, at 17:41, Jens Alfke

Re: Who owns a child view controller?

> On 12 Jul 2017, at 18:38, Charles Srstka wrote: > >> On Jul 12, 2017, at 12:23 PM, Jens Alfke wrote: >> >>> On Jul 12, 2017, at 9:54 AM, Jeremy Hughes >>> wrote: >>> >>> I’d forgotten about autorelease pools - but

Re: Who owns a child view controller?

> On Jul 12, 2017, at 12:23 PM, Jens Alfke wrote: > > >> On Jul 12, 2017, at 9:54 AM, Jeremy Hughes >> wrote: >> >> I’d forgotten about autorelease pools - but I guess they’re still there in >> Cocoa for backwards compatibility with pre-ARC

Re: Who owns a child view controller?

> On Jul 12, 2017, at 9:54 AM, Jeremy Hughes > wrote: > > I’d forgotten about autorelease pools - but I guess they’re still there in > Cocoa for backwards compatibility with pre-ARC code. Autorelease is still necessary with ARC. There are cases where ARC doesn’t

Re: Who owns a child view controller?

> On 12 Jul 2017, at 17:41, Jens Alfke wrote: > > There may still be a reference in the autorelease pool. Check childReference > again ‘later’, i.e. on the next user event or after a timer/delayed-perform. Thanks. I’d forgotten about autorelease pools - but I guess they’re

Re: Who owns a child view controller?

> On Jul 12, 2017, at 9:34 AM, Jeremy Hughes > wrote: > > // Prints "Why is childReference not nil?” There may still be a reference in the autorelease pool. Check childReference again ‘later’, i.e. on the next user event or after a timer/delayed-perform. —Jens

Who owns a child view controller?

I’m trying to understand who owns a child view controller after it has been removed from its parent view controller. The following code (which doesn’t involve view controllers) behaves as I would expect: import Cocoa class Element { var children = [Element]() weak var parent:

Re: cell-based NSTableView, NSArrayController and first responder

On Jul 12, 2017, at 4:52 AM, Martin Hewitson wrote: > > I have a new bug in an application which I believe has only appeared in 10.12. > > I have a cell-based NSTableView backed by an NSArrayController, and the (new) > problem I have is that the editing of a cell

cell-based NSTableView, NSArrayController and first responder

Dear list, I have a new bug in an application which I believe has only appeared in 10.12. I have a cell-based NSTableView backed by an NSArrayController, and the (new) problem I have is that the editing of a cell ends after the first keystroke. It looks as if first responder is resigned, but I