Apache OpenOffice (AOO) Bugzilla – Issue 24234
Doc is formatted before setting the correct window size
Last modified: 2013-02-07 22:20:14 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.
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.
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
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)
changed target to Office later
MMP>MBA: I have no problems with a flicker in this limited set of cases. (BTW I set the target baclk to OOo2.0)
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.)
.
os->fme: The state method calls SwCrsrShell::IsInVerticalText() / IsInRightToLeftText() How should this method know about an invalid window size?
FME->AMA: Looks like we are playing ping-pong. Please decide what to do.
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".