Issue 24234 - Doc is formatted before setting the correct window size
Summary: Doc is formatted before setting the correct window size
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 1.1.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2004-01-09 11:06 UTC by frank.meies
Modified: 2013-02-07 22:20 UTC (History)
1 user (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description frank.meies 2004-01-09 11:06:34 UTC
In SRX645/SRC680 (in opposite to SRC641), I noticed that SwView::GetState() is
called before SwView::OuterResizePixel(). SwView::GetState() with
SID_IMAGE_ORIENTATION results in a formatting of the layout with an incorrect
window size for documents in online layout. 

FME->MBA: Please re-check the target.
Comment 1 Mathias_Bauer 2004-01-09 12:25:45 UTC
The reason is that we try to set the correct state to all toolbox images before
they are painted, so we have to query for the image orientation before we can
paint any toolbox items (because we don't know wether any of them needs this
state, we ask for it anyway).

At that time the size of the view is not known, because a resize event was still
not received.

I see two options: postpone the status retrieval until a resize event was
received and(!) processed or completely do the status update asynchronously. 

The first option is more elaborate, more errorprone and needs a little bit more
"hacking". The second one is easy and straightforward, but has the disadvantage
that toolbox items might show the wrong state when they are shown and only in
less than a seond later show the right one. There is no problem with a possibly
wrong state when you click on a toolbox in the short timespan it takes to update
the state, because a click always triggers the state retrieval before anything
else is done.

I would like to hear the opinion of the user experience group in that matter.
The target is OK for me.
Comment 2 matthias.mueller-prove 2004-01-21 16:23:41 UTC
Hi Mathias, can you please add some more meat to the description. I have
absolutely no clue which button shows what effect and why. Thanks Matthias
Comment 3 Mathias_Bauer 2004-01-21 17:31:15 UTC
We need the status for "image rotation", because some images are rotated
depending on the writing direction of the current paragraph.

Unfortunately the writer calculates the layout to retrieve this information but
doesn't have the right window size.

We have two options:
- don't retrieve any status information before the document is visible; this
might result in some flickering of the toolbar buttons and windows when they
receive their "real" status later. As I wrote, the principal problem that we ask
for status information before the document is visible is not restricted to this
only case.
- fix it in Writer only for the "image rotation" status and allow only these
items to flicker (and all other status info that needs calculation of layout)
Comment 4 matthias.mueller-prove 2004-02-20 15:55:36 UTC
changed target to Office later
Comment 5 matthias.mueller-prove 2004-02-23 14:07:03 UTC
MMP>MBA: I have no problems with a flicker in this limited set of cases. (BTW I
set the target baclk to OOo2.0) 
Comment 6 Mathias_Bauer 2004-02-23 16:53:43 UTC
So the implementation for updating "SID_IMAGE_ROTATION" should be changed in a
way that it doesn't make an OuterResizePixel but instead returns a default value.

Immediately after a cursor has been created, the slot should be invalidated
anyway and the correct status will be retrieved.

BTW: IMHO *all* status information should just return a value and never do any
elaborate work (like swapping in graphics etc.)
Comment 7 Oliver Specht 2004-03-15 07:59:15 UTC
Comment 8 Oliver Specht 2004-06-09 12:40:55 UTC
os->fme: The state method calls SwCrsrShell::IsInVerticalText() /
How should this method know about an invalid window size?
Comment 9 frank.meies 2004-06-09 12:55:16 UTC
FME->AMA: Looks like we are playing ping-pong. Please decide what to do.
Comment 10 andreas.martens 2004-06-11 17:25:56 UTC
We will assure that no status request will do a formatting. But this needs some
time for implementation. Because there's no really visible problem for the user,
I change the target to "OOo Later".