To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=105259
User fs changed the following:
What|Old value |New value
Target milestone|OOo 3.x |OOo Later
--- Additional comments from f...@openoffice.org Wed Oct 14 11:12:26 +
2009 ---
giving up on this ... :(
I spent quite some time debugging this, discussing the involved component's
behavior with their owners, and trying various approaches to fix this. The
collaboration between the layout manager, the embedded object, the Writer
document, the outer and inner window size, and the so-called visual size of
the embedded object is that complex, undefined, in parts working-by-luck only,
that a reasonable solution to the problem would take more time than I can
reasonably justify to invest into this kind of issue: I consider this a pretty
ugly thing, but it's not worth the tremendous effort needed to fix it.
Techcanilly, for later reference, the problem is as follows:
The form is loaded visibly, so the first occurrence you see on the screen is a
top-level window in a sized defaulted by the OS. Then, the content size of the
previous incarnation of the form is restored. This content size (in the UNO
API referred to by embed::Aspects::MSOLE_CONTENT) can be understood as the
window size, minus all the toolbar, menu bar, status bar sizes. So, the second
occurrence is a properly-sized window. Third, this window is centered on the
screen, which is the third occurrence.
While it is easily possible to load the document hidden, this immediately
provokes all kind of problems. Effectively, the window would come up nearly
zero-sized with this:
Setting the content size is forwarded to SfxObjectShell::setVisualAreaSize,
which applies some magic to resize the whole window: It calculates the
difference between the previous VisualAreaSize and the newly requested one, and
resizes the complete window by this difference. Now this silently assumes that
the window size and the visual area size are always coupled, which is not
remotely the case: There are other places where the window size is modified,
without touching (or even knowing about) the VisualAreaSize of the contained
document. So effectively, when the document is loaded hidden, and the layouting
of the toolbars/menu/statusbar did not happen, yet, then setVisualAreaSize does
the completely wrong thing.
There simply is no well-defined point (at least I didn't find one) where it is
known that the initial layouting is finished. This point would be needed to
properly set the window size, calculating from the desired content size and
the sizes of all the UI elements.
The best version I could come up with was one where the window didn't jump at
all (since it was loaded hidden), but appeared slightly smaller than in its
previous incarnation. This is something I also do not consider acceptable, as it
means that during designing your form, you need to re-adjust its size to what
you desire for it every time you close and re-open it.
So, I am moving the target milestone of this to Later.
-
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...@dba.openoffice.org
For additional commands, e-mail: issues-h...@dba.openoffice.org
-
To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org
For additional commands, e-mail: allbugs-h...@openoffice.org
