To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=111452
User mba changed the following:
What |Old value |New value
================================================================================
Status|NEW |RESOLVED
--------------------------------------------------------------------------------
Resolution| |FIXED
--------------------------------------------------------------------------------
Target milestone|--- |OOo 3.x
--------------------------------------------------------------------------------
------- Additional comments from m...@openoffice.org Tue May 11 12:47:27 +0000
2010 -------
Thanks for the patch, it helped me to find the culprit. OTOH I solved the
problem differently. It took some time to analyze this problem.
The reason for the assertion is that getController() is called at a disposed
frame and its TransactionGuard complains about that by showing the assertion
message. The offending call happens in the AsyncCallback of the CloseDispatcher
(the code that you have patched).
The idea of this code is that once a Controller has been suspended in
preparation for closing the frame, this suspension must be removed when the
closing of the frame failed. Otherwise the UI inside the frame would be
dysfunctional and perhaps a crash is not far away.
The code makes a mistake by assuming that "bSuccess" being sal_False is enough
to detect the need to "unsuspend", but unfortunately the variable is can have
this value also if the frame was closed successfully, but the Desktop could not
be terminated. This is the case e.g. if a Quickstarter is active.
Your patch just checks if the frame was actually destroyed, but it will fail in
case any other code still has a "hard" reference to the frame.
My first attempt was to have two variables "bSuccess" (for the overall access of
the whole method) and "bCloseSuccess" that will be true only if the frame was
closed successfully by the CloseDispatcher. Unfortunately after some thinking I
discovered scenarios where the Controller was suspended, but the frame was
closed or tried to be closed elsewhere, so "bCloseSuccess" is not able to
provide the needed information.
What we want to know is: was the frame disposed so that calling getController()
is not necessary? A possible solution would be to register an EventListener at
the frame that notifies the CloseDispatcher about the disposing event. But IMHO
that would be overkill. I think it is OK to remove the TransactionGuard from the
Frame::getController() method. This makes clear that calling getController() at
a disposed frame is not a mistake. I can't think of a situation where this would
cause trouble: getController() just returns a copy of a member variable that is
not guaranteed to be not empty.
---------------------------------------------------------------------
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...@framework.openoffice.org
For additional commands, e-mail: issues-h...@framework.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
