Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSPopUpButton...

[Fred Kiefer]

Enrico Sersale wrote:
> On 2005-05-30 20:09:27 +0300 Fred Kiefer <address@hidden> wrote:
> > could you please describe in detail how to reproduce this bug? I tried 
> > before and after applying the latest patch be Matt and faild to find 
> > the correct order of operations to reproduce it.
> > And are you sure this patch was the reason for the traceback not the 
> > other one? 
>
> Yes. Using the latest CVS and substituting in it *only* 
> NSPopUpButtonCell.m fixes the bug.
> To reproduce it:
> with GWorkspace: close a window that contains a popup (you must put it 
> in "spatial" mode "View->Viewer behaviour->Spatial").
> with GNUMail: do something that closes a window, for example, try to 
> send a message.

Thank you, this allowed me to reproduce the problem. Tracking it down 
was a lot harder. I am still not completely sure that I do understand 
the problem completely. My current opinion is that, when closing the 
(not displayed) menu of a popup, because the window it is on gets 
deallocated, the window of the menu gets ordered out and this calls the 
NSWindow method _lossOfKeyOrMainWindow. In that method an array of all 
windows is build up, even when this is not needed. When that array will 
get deallocated by the surounding autorelease pool, this will once more 
deallocate the window to the popup was one, as this will still show up 
in the window list, although it was already in the process of being 
deallocated.
One easy way to work around this for this specific case is of course to 
only close the menu of the popup, if it was visible. That way the 
general problem will remain that one should never call orderOut: while 
another window may get deallocated. Perhaps somebody has an idea on how 
to fix this in general?

Cheers
Fred