[Drawkit] bug?

[Graham Cox]

Well... doesn't look like a bug in DK as such. Hard to say exactly why  
this cropped up, but you shouldn't be releasing your controllers  
anyway - they are not typically yours to release.

There are two scenarios that lead to the deallocation of a tool  
controller. 1. the view that the controller is associated with goes  
away. This might happen because the window on which it lives has  
closed, or you removed it from a superview, etc. In that case, the  
view removes the controller from the drawing which releases it. 2. The  
drawing goes away. This might be because the document that owns it has  
closed, and all of the windows and views associated with it are  
getting torn down. In that case, the drawing releases all of the  
controllers it might have. It doesn't matter whether the view or the  
drawing goes away first - the right thing gets done. (This is well- 
tested because getting this to work properly - i.e. not leak, and not  
have retain cycles - for all the different cases took a lot of testing!)

If some other object has retained the tool controller other than its  
proper owner (the drawing) then you could run into problems because a  
"naked" tool controller that is not attached to a drawing and/or a  
view is not only going to be useless, but may have stale weak refs to  
objects that might have disappeared. You're on a fast-track to crash  
city. So don't retain tool controllers - just let them work as they  
are supposed to.

The problem could also be that you somehow broke a connection between  
a view and its controller without removing the controller from the  
drawing (normally this won't happen if you just leave things to run  
their course) and when the drawing was dealloced (on doc closure) it  
asks all of its controllers to close any editing sessions that may be  
open. At that point if the controller is in a bad state then it could  
also be trying to reference a non-existent view. Normally that will  
crash but just maybe the ref now points to an array instance in memory  
and that's why you are getting this message. The advice is the same -  
just let tool controllers work normally.

None of this precludes overriding or subclassing a tool controller,  
but it's important not to do this in order to interfere with its  
normal ownership and lifetime mechanisms. Because of the need for weak  
references in both directions within a tool controller, this is one of  
the more sensitive and subtle classes when it comes to memory  
management.

cheers, Graham



On 8 Aug 2008, at 12:46 pm, James Maxwell wrote:

> I added a dealloc to my DKDrawingDocument subclass, and a strange  
> error appeared:
>
> *** -[NSCFArray exitTemporaryTextEditingMode]: unrecognized selector  
> sent to instance 0x15ed5c90
>
> It pops up when I release my DKToolController subclass - in  
> particular, it's when I close a drawing that has been read from  
> disk. I worked around it by handling my controllers in a much better  
> way, and thus avoiding the need to release them in a dealloc, but I  
> thought I'd post the error anyway, as it doesn't seem like it should  
> be possible for this selector to be sent to a NSCFArray (should only  
> be sent to controllers, from what I can tell).
>
> J.
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net