Re: Trouble with toolbars

[Fred Kiefer]

Wolfgang Lux wrote:
>> To summon up what happens: The window gets deallocated to clean up it
>> frees the toolbar which results in a resize of the content view and this
>> ends in GormGenericEditor refreshCells where an invalid document
>> instance variable gets dereferenced.
>> Now in this specific case it surely would help to get Gorm to clean up
>> the document instance variable and there is already code to do so, most
>> likely it is just not working in this specific case. (Closing the
>> project first and then quiting Gorm works)
>> After a long analysis I would suggest to call willCloseDocument: from
>> close: either in GormGenericEditor or GormObjectEditor, the actual class
>> that causes this problem. (Greg, could you please verify this solution?)
> 
> Just a small note: I do not understand why the content view of the Gorm
> window is resized at all in this case. If the toolbar is part of the
> window's
> decoration view the content view of the window should not change its frame
> at all if the toolbar is inserted or removed, except maybe for those border
> cases where the whole window is resized in order to fit within the screen
> (however note that NSWindow on Mac OS X 10.4 and earlier does not show this
> behavior, so maybe you shouldn't care either -- at least until the toolbar
> implementation stabilizes).
> 
Thank you for looking into this. The resizing of the content view is
just an artefact of my current implementation of how I add the toolbar
into the window.
What I currently do when adding a toolbar is decreasing the content view
size and then increasing the window frame. The window frame change will
trigger a resize of the decoration view which will result in an increase
of the content view. I hope to come up with a better way soon, the
reason I did it this way was that with that all the view sizes are
consistent all the time. What I could try to do is to increase the
decoration view size, when adding the toolbar, that way when the frame
setting of the window results in a set frame for the decoration view, it
already has the right size (even when the window is set to a smaller
frame the relation between the different views will be correct)
I also have to find out whether Richard is correct and our standard
subview resizing could do the trick here and the additional resizing
code here could go away.

>> How to proceed? If you would know, I wouldn't be writing this mail :-)
>> What I would like to do is rewrite the toolbar framework, so that the
>> toolbar retains the toolbar view and not the other way round. There is
>> one big drawback to that, it makes it harder to code stand alone
>> toolbars, where the toolbar isn't embedded in the window, instead it is
>> in the normal view hierarchy. For that case we will then have to retain
>> the toolbar and for code like ToolbarExample this would result in a
>> memory leak. Is this acceptable?
> 
> I just did a quick test with Apple's ObjectAlloc and it looks like on
> Mac OS X the toolbar retains its view and not vice versa. In addition,
> the toolbar itself is retained by the window upon passing it to
> -setToolbar:. This means that if a program wants to insert a toolbar
> view into the view hierarchy at some other point it remains the owner
> of the toolbar and is responsible for releasing the toolbar when the
> toolbar view is removed from the view hierarchy or the whole window
> is closed. A memory leak of course isn't acceptable, but then it looks
> like there is an error in ToolbarExample if it does leak (I haven't
> looked into its source, though).

That sounds ok to me, I will change the interaction between the toolbar
and the view in that way and leave the example with a memory leak (and a
comment expressing why).

Thank you
Fred