Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Form position "jumps" during opening it, leaving screen clutter until completely loaded|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description ud 2009-09-22 10:43:06 UTC
If i open a form with double click on it, it opens twice or more. If the data for the form is already load, the second form will be closed in the background. It looks for me, that the first form is opened in design view? And in the background it looks like another window with no identification from my side.
Comment 1 ud 2009-09-22 10:44:45 UTC
Created attachment 64890 [details] Screenshot taken with DEV300m59
Comment 2 ud 2009-09-22 10:55:35 UTC
Created attachment 64891 [details] Screenshot that shows 3 windows better
Comment 3 Frank Schönheit 2009-09-23 21:15:44 UTC
can reproduce this. It's better to see in a (slower) non-product build. I do not really think the form opens twice, to me it looks as if the form is opened, positioned somewhere, and then moved to its final position. Immediately after that, the connection to the database is established, and the data is loaded. This is expensive, and during that time, no re-painting happens. In particular, the database window is not repainted, so that the fragments of the form, from its old position, are still visible. You can verify this by making the database window pretty small, and opening the form. Indeed now the "zombie" incarnation of the form is only to be seen over the database window, not over remaining parts of the screen, which means this incarnation is not really there. Trying to express this in a new summary. Confirming, grabbing, targeting.
Comment 4 Frank Schönheit 2009-10-14 12:12:26 UTC
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".