Thanks to Mike Ash in an IRC chat, I believe I have the answer to this
particular question.
Memory Management Programming Guide - Weak References
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmObjectOwnership.html#//apple_ref/doc/uid/20000043-1044135-BCICCFAE
I believe this accurately describes the situation using the tracking area. They
had a weak reference to the window controller, if they did not, we would have a
classic retain cycle.
Hence, the right thing to do is for the Window Controller, since it created the
weak reference, to clean it up when being deallocated.
Any additional thoughts would be of interest.
On Jan 18, 2011, at 2:46 PM, Eric Gorr wrote:
> This seems like it should have an easy answer and one that I should know, but
> my brain has frozen up on this and I cannot seem to determine if things are
> working as expected or if there is something more I should be doing.
>
> First, here is a sample project that demonstrates the behavior I am seeing:
>
> http://ericgorr.net/cocoadev/trackingarea.zip
>
> Once you build and launch the application, a window will appear with a single
> button with the label 'Button'. Push the button.
>
> After pushing the button, another window will appear. This is a modal window
> run using NSApplication's runModalForWindow. It is also owned by the
> WindowController class.
>
> The second window has a single button on it with the label 'Quit'. Push the
> button.
>
> This will call NSApplication's stopModal method and everything will be
> deallocated.
>
> So, what's the problem you might be wondering? Well, it is the order of
> deallocation and the unexpected delay in deallocating the window.
>
> What you will see if you put a breakpoint in the dealloc method of the window
> is that the window is deallocated long after the pushed: method in
> trackingareaAppDelegate has finished and the WindowController has gone away.
>
> Now, in the case of the real application, the window has a view which has a
> tracking area and the tracking area wants to call a method in the
> WindowController. For some reason, the after the controller was deallocated,
> but before the window is deallocated, the tracking area calls into the window
> controller one last time and the application crashes. (My sample app won't
> crash)
>
> So, what I am wondering is why my window is staying around...? I would have
> thought that after the window controller was deallocated, that the window
> would be as well. Is there a way to force the window to be deallocated before
> the controller is deallocated?
>
> The only solution I can come up with is that the window controller needs to
> make sure the tracking area has been removed before it is fully deallocated.
> Is this what I should be doing? Should the WindowController's dealloc method
> be written as:
>
> - (void) dealloc
> {
> [aView removeTrackingArea:myArea];
> [aView release];
>
> [super dealloc];
>
> NSLog( @"WindowController Dealloc" );
> }
>
> While my sample project isn't crashing, I figure that is only because I am
> getting lucky and the tracking area is not firing one last time after the
> controller has gone away.
_______________________________________________
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 arch...@mail-archive.com
