Re: Mysterious crash with NSTableView
Re: Mysterious crash with NSTableView
- Subject: Re: Mysterious crash with NSTableView
- From: Kyle Sluder <email@hidden>
- Date: Sun, 28 Aug 2016 19:10:07 -0500
On Sat, Aug 27, 2016, at 03:55 PM, Andreas Falkenhahn wrote:
> On 27.08.2016 at 18:10 Alex Zavatone wrote:
>
> > Buuut, to the mind of the person learning this or trying to fit all
> > the complexity of learning this in their head, it might be wise in
> > the docs to remind the programmer that they need to do this and why
> > with a, "just in case you are assuming that your code is ready to
> > function now, please remember that the objects that end up making a
> > working tableView require that the tableView's dataSource object
> > and delegate object need to be assigned, generally to the hosting
> > view controller's instance of self. If this causes you to raise an
> > eyebrow in confusion, the reasons why you must do this are xxx and
> > yyyy. Likewise upon deallocation of the tableView (if it gets
> > called), these objects will need to be set to nil after zzzz but
> > before the tableView object is able to dispose of itself."
>
> Huh? "Remember that you have to set this property to nil before you
> release the object" would already be sufficient...
>
> By the way, I still don't know whether setting the delegate to nil
> before release is a general rule or does it only apply to NSTableView?
> Should I also set my button delegates to nil before the buttons are
> released?
Buttons don’t have delegates; they have targets.
Generally applications work fine without nilling out the targets of
their controls. This only works because controls almost exclusively
message their targets synchronously on the main in response to user
actions. There’s no opportunity for one of the target’s dependencies to
be deallocated in between the user triggering the target-action message
and the target receiving the action message.
Delegates are different because they are often messaged in response to
various exogenous events. Some of these events might happen transiently
during window teardown, which is usually a time of massive fluctuation
in an app’s object graph. This is why -windowDidClose: is a good time to
nil out delegate properties that point back and the window controller
which ultimately owns the control.
That said, it is totally possible for a control to delay-perform sending
an event, and even if it takes pains to make sure it doesn’t message the
_target_ if it’s been deallocated, one of the target’s _dependencies_
might have been deallocated. These cases are usually found after much
swearing and trial-by-fire. Such is the difference between theory and
practice.
--Kyle Sluder
>
> --
> Best regards,
> Andreas Falkenhahn
> mailto:email@hidden
_______________________________________________
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