[Drawkit] bug?

[James Maxwell]

Hi, Graham,

Yeah, I realized that the releasing of controllers was all taken care  
of... I had been having a problem with the controllers not get set up  
properly when loading from a saved file. This was just a problem with  
where I was creating the controllers for my two views. I figured that  
out, and was able to get rid of the controller releases in my dealloc  
(well, I just got rid of the dealloc altogether!).

I just wanted to post it, in case it was revealing a bug. But your  
idea that the reference might have been left pointing to an array  
instance is probably correct.

cheers,

J.



On 8-Aug-08, at 7:24 AM, Graham Cox wrote:

> 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
>
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net