Issue 105259 - Form position "jumps" during opening it, leaving screen clutter until completely loaded
Summary: Form position "jumps" during opening it, leaving screen clutter until complet...
Status: CONFIRMED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: DEV300m59
Hardware: PC Windows XP
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-22 10:43 UTC by ud
Modified: 2017-05-20 10:44 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Screenshot taken with DEV300m59 (117.15 KB, image/png)
2009-09-22 10:44 UTC, ud
no flags Details
Screenshot that shows 3 windows better (117.10 KB, image/png)
2009-09-22 10:55 UTC, ud
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
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".
Comment 5 Marcus 2017-05-20 10:44:57 UTC
Reset the assignee to the default "issues@openoffice.apache.org".