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 +0000 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