To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=99010
------- Additional comments from f...@openoffice.org Mon Feb 9 13:20:05 +0000 2009 ------- setting m_bHasAWTMenuBar in VCLXTopWindow_Base, but evaluating it in VCLXTopWindow only, is definitely Not Good (TM): If there are (or will be) other derivations of VCLXTopWindow_Base (and I suppose there are, since the class is declared DLL_PUBLIC), then they will still suffer from the same problem, sooner or later. The proper solution here is to introduce a "dispose" method at the VCLXTopWindow_Base class, and make sure that all existing derived classes call this method in their own dispose call (and leave a comment for future derived classes). As for VCLXTopWindow::dispose: Do not call into the base classes "dispose" with the own mutex locked. Their might be places in the base class method which acquire/release their own mutex, and rely on this being the only lock. As a general note, I think the approach is valid to solve the particular problem, but to me it looks as if there's a can of worms in the VCLXMenu/XMenu/Menu(*) implementation/API. Originally, I wanted to mention that the VLCXTopWindow_Base should of course be a listener at the XMenu, to know when its being disposed, and thus the underlying Menu dies. Assuming that the VCLXMenu is of course the owner of the Menu, since it created it ... Now from looking at the code it seems that the Menu represented by a VLCXMenu *never* dies. Huh? We do not seem to have a clear ownership concept here: Creating a css.awt.Menu and releasing it leaves a memory leak, so it seems to me. On the other hand, now with the patch, the MenuBar is implicitly deleted in SystemWindow::SetMenuBar( NULL ) (but *not* when SetMenuBar would be called with a non-NULL new menu bar - what weird logic is this, really?), so it seems the SystemWindow assumed ownership of the menu bar. Strange indeed ... Admittedly, this is not related to the patch here ... --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@api.openoffice.org For additional commands, e-mail: issues-h...@api.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
