Issue 115551 - Button anchored as character or to the paragraph take all the room
Summary: Button anchored as character or to the paragraph take all the room
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 3.3 RC4
Hardware: All All
: P3 Trivial (vote)
Target Milestone: 3.4.0
Assignee: marc.neumann
QA Contact: issues@dba
Keywords: regression
Depends on:
Reported: 2010-11-12 07:41 UTC by jbf.faure
Modified: 2017-05-20 10:30 UTC (History)
6 users (show)

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

bugdoc (11.54 KB, application/vnd.sun.xml.base)
2010-11-12 07:43 UTC, jbf.faure
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jbf.faure 2010-11-12 07:41:45 UTC
Steps to reproduce :
1/ open the attached odb file
2/ open the form Formulaire1 : the button take all the room

If you anchor the button to the page, it works well.

The problem does not occur in OOo 3.2.1

Verified in OOO330m9 under Ubuntu and OOo 3.3.0 RC4 under XP.

Comment 1 jbf.faure 2010-11-12 07:43:06 UTC
Created attachment 74668 [details]
Comment 2 vitriol 2010-11-12 08:10:49 UTC
Adding me to CC
Comment 3 Frank Schönheit 2010-11-12 08:43:06 UTC
Comment 4 Frank Schönheit 2010-11-12 08:48:52 UTC
fs->aw: Need your expertise here ...

There are (at least) two differences between the case where the control shape is
anchored to paragraph (in which case it is displayed wrong) and the case where
it is anchored to page (in which case it is displayed correctly):

First, the LogicRect as returned by SdrTextObj::GetLogicRect is 0,0,2267,1133 in
the "bad" case, and "568,568,2835,1701" in the good case.

Second, the object-to-view transformation as passed to my primitive's
|create2DDecomposition| method, i.e. the transformation as returned by
ViewInformation2D.getObjectToViewTransformation, for the ViewInformation2D
instance passed into |create2DDecomposition|, has a scale of 2/30 (each
direction) and a translation of -37.866666 (each direction) in the "good" case,
and scale 1,1 / translation "0,0" in the "bad" case.

I'd say the root cause is with the view information here - thus I'd ask you to
have a look into this.
Comment 5 Armin Le Grand 2010-11-12 09:55:16 UTC
AW->FS: Taking a look. I have to mention that i am doing basic changes to
DRawinglayer currently and my last CWS integrated which may have changes is
AW083 on 2010-07-09. Is there information since when this task happens?

AW->FS: 2nd question: Does it work well with a simple draw Rechtangle? If Yes,
the difference will most likely be in the form control stuff.

AW: Checking if this happens and is evaluable with my current CWS...
Comment 6 Frank Schönheit 2010-11-12 10:03:19 UTC
fs->aw: it doesn't happen with an ordinary rectangular shape, however, this
isn't too surprising: As far as the SdrObjects are concerned, everything is
okay. Just in the drawing layer, the view transformation seems to be wrong,
which is used to size the resulting VCL window (which doesn't exist for the
other shape types).

For your first question: Will try a few older versions to see if I can find out
where the bug came in ...
Comment 7 Frank Schönheit 2010-11-12 10:06:52 UTC
Ouch. This broke between DEV300.m50 and DEV300.m60 :-\ (Don't have too many of
*that* old intermediate milestones anymore, so can't find out more precise.)
Comment 8 Armin Le Grand 2010-11-12 11:45:03 UTC
AW: It looks like the ViewInformation2D at the ObjectContact (Its a
ObjectContactOfPageView) is not initialized when ViewObjectContactPrimitiveHit
is triggered to check for object hit. This seems to be the only action which
causes a sequence of primitives to be asked for. There seems to be NO redraw
going on at all. The form design view seems to be based on SW (seen on the
stack) but somehow, no repaint comes through to the Drawinglayer. Checking why
this is the case...
Comment 9 Armin Le Grand 2010-11-12 11:58:23 UTC
AW: Indeed, SwEditWin::Paint (and thus the whole DrawingLayer repaint) is never
called. I guess this is because the button covers the whole window. Since the
form control is in live mode, it's a VCL child window and thus the whole area of
the edit window IS covered and will be clipped from the repaint.
When no DrawingLayer repaint is executed, the ViewInformation2D at the OC will
never be updated and thus always stay on the default empty state which also
includes an empty ViewTransformation.
Checking how this could be solved...
Comment 10 Armin Le Grand 2010-11-12 12:06:57 UTC
AW: Thought about also initializing ViewInformation2D before
ViewObjectContactPrimitiveHit calls (which is currently done lazy by painting
what does not hurt in principle), but this will not work. When playing around
with the document zoom slider in the bottom right of the window it can be seen
that the controls will not be resized at all; this is probably also because the
Paint is not executed. Currently, the positioning (and thus also the zooming) is
all done inside the paint as we know. A PostPaint() is probably also not a big
help: i guess it would also not be called since the clipping and decision not to
paint is done in VCL.
Most simple and best solution would be to somehow trigger the paint of the
hidden window. Maybe the control could be completely not shown
(ViewObjectContactOfUnoControl::createPrimitive2DSequence returning an empty
sequence when the ViewTransformation is empty). This would be a fix for the
moment, but as soon as someone ever zooms the view in a way that a control in
live mode once covers the edit window completely, the same situation will show
up again.
Checking if returning an empty sequence when the ViewTransformation is empty
will help...
Comment 11 Armin Le Grand 2010-11-12 12:23:47 UTC
AW: It behaves exactly as i expected. Diff is:

diff -r d7e46c52a8d3 svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
--- a/svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx	Fri Oct 01
16:29:04 2010 +0200
+++ b/svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx	Fri Nov 12
13:15:41 2010 +0100
@@ -1818,6 +1818,9 @@
             // disposed the control though it doesn't own it. So, /me thinks we
should not bother here.
             return drawinglayer::primitive2d::Primitive2DSequence();
+            return drawinglayer::primitive2d::Primitive2DSequence();
         // ignore existing controls which are in alive mode and manually
switched to "invisible"
         // #102090# / 2009-06-05 /
         const ControlHolder& rControl( m_pImpl->getExistentControl() );

This is NOT a longtime solution, but will make the initial visualisation work.
Indeed when once zooming so that the utton covers the whole view, the problem is

AW->FS: Feel free to use this mediorce solution. It clearly shows that not even
our discussed Pre/Post/Paint is an adequate solution, but we need something
independent from paint which layouts the controls in live mode if needed (e.g.
Zoom, object change, You name it...). Due to the one always in live mode control
this is always needed.
Comment 12 Frank Schönheit 2010-11-12 12:24:15 UTC
works in DEV300.m51, is broken in DEV300.m52
Comment 13 Frank Schönheit 2010-11-12 12:49:57 UTC
Thanks for the investigations.

However, this leaves quite some of questions:
- is checking the transformation for identity really feasible? Are there no
  "real-life" cases where the transformation is the identity, e.g. in other
  applications? I'd not have a good feeling with this.
- Why does it work in OOo 3.2.0 and OOo 3.2.1? The OOO320 code line was split
  from m60, where the bug already exists. Somewhere on the way to OOo 3.2.0
  it was fixed, unintentionally.
- Why does changing the anchor type make the problem vanish?
Comment 14 Armin Le Grand 2010-11-12 13:14:59 UTC
- Yes, theoretically an empty ViewTransformation could happen and i already
thought about it. It's a workaround. It's potentially less likely than someone
zooming so that a control in life mode covers the whole DrawingLayer VCL-Window...

- i have no idea for the other two questions, but would definitely be
interested, too...
Comment 15 Oliver-Rainer Wittmann 2010-11-12 13:54:28 UTC
I tried to reproduce the described defect under Windows with NON-PRO
installation sets of a couple of DEV300 milestones:
- m52, m60 and m61 show the defect
- m62, m64, m68 and m69 work fine
- m70, m71, m72, m75, m80 and m90 show the defect
--> something happens in m62 and m70
Comment 16 Frank Schönheit 2010-11-12 13:54:52 UTC
targeting to 3.4, since it has been rejected for 3.3.
Comment 17 Frank Schönheit 2010-11-12 14:28:44 UTC
good catch ...

m62 integrated CWS dba33h, so this one likely fixed the bug.

m70 integrated CWS dba33b, so this one likely brought the bug back.

reverting m70's changes to svx/inc/svx/sdr/contact/*uno* and
svx/source/sdr/contact/*uno* fixes the problem.

The (non-merge) changesets between m69 and m79 which affected
viewobjectcontactofunocontrol.cxx are:

changeset:   264436:34f79e794856
user:        Frank Schoenheit [fs] <>
date:        Wed Oct 28 09:50:28 2009 +0100
summary:     #i106368#

changeset:   264437:2b6c20513ac6
user:        Frank Schoenheit [fs] <>
date:        Thu Oct 29 08:29:49 2009 +0100
summary:     getZoom: access the peer, not the control, for getting
implementation access

changeset:   264797:3338508d0caf
user:        fs
date:        Thu Jul 16 09:23:47 2009 +0000
summary:     ensureControl and friends: pass an initial view transformation,
this later saves a positionAndZoomControl call in createLocalDecomposition

Somehow I think revision 264797 is the problematic one here ...
Comment 18 Frank Schönheit 2010-11-12 21:48:26 UTC
fs->aw: looking at the changes which came in with the above-mentioned CWS, I
still think they are correct. I still think that it is incorrect for the drawing
layer to pass a ViewInformation2D instance which delivers the identity view
transformation - that's merely wrong, in my opinion, and something which should
be fixed in the drawing layer.

fs->od: I further investigated the difference between the two anchor cases.
Interestingly, in the "good" case, the hit test simply ignores the SdrObject.
This is in SdrObjectPrimitiveHit (sdrhittesthelper.cxx), because
SdrObject::GetLayer returns "5" here, and layer 5 is not visible. So, the hit
test will never ask the control's VOC for a primitive sequence, so the VOC has
is not fouled by the broken ViewTransformation.

In the "bad" case, however, the SdrObject is on layer 2 - which is visible.
Consequently, the drawing layer lets the VOC create the primitive sequence,
which leads to the wrong behavior (due to the broken ViewTransformation).

I'd be grateful if you could investigate on this difference in object layers -
not sure there's still some Writer problem hidden here.

Other than that, I am tempted to assign this issue back to aw, since I still
think it's a drawing layer bug, but I think we can discuss this f2f first ...
Comment 19 Armin Le Grand 2010-11-13 15:54:25 UTC
AW->FS: I already explained that currently for HitTest the 'lazy'
ViewTransformation setting from Paint is used (which is not optimal but does no
harm). Changing that would be okay but lead to the same initial solution as
ignoring the empty transformation (the patch), but not more. 

It will also not fix this issue; to fix it, we will have to think about
something completely independent from Paint, at least for controls which ARE
Comment 20 Frank Schönheit 2010-11-15 08:24:07 UTC
fs->aw: ah, sorry, didn't read from your first comments that the empty
transformation is the expected behavior.
Comment 21 Frank Schönheit 2010-11-23 21:31:38 UTC
fixed in CWS dba34b, by committing the preliminary fix suggested by aw.
Submitted follow-up issue 115754 for a clean and complete solution.
Comment 22 Frank Schönheit 2010-11-29 09:25:32 UTC
fs->msc: please verify in CWS dba34b
Comment 23 marc.neumann 2011-01-21 12:53:02 UTC
verified in CWS dba34b

find more information about this CWS, like when it is available in the master
builds, in EIS, the Environment Information System: