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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev