Enrico Sersale wrote:
On 2005-05-30 20:09:27 +0300 Fred Kiefer <[EMAIL PROTECTED]> 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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
