Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Button anchored as character or to the paragraph take all the room | ||||||
---|---|---|---|---|---|---|---|
Product: | Base | Reporter: | jbf.faure | ||||
Component: | code | Assignee: | marc.neumann | ||||
Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | Armin.Le.Grand, frank.schoenheit, issues, mdxonefour, orw, vitriol_vitriol | ||||
Version: | OOo 3.3 RC4 | Keywords: | regression | ||||
Target Milestone: | 3.4.0 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
jbf.faure
2010-11-12 07:41:45 UTC
Created attachment 74668 [details]
bugdoc
Adding me to CC grabbing 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. 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... 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 ... 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.) 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... 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... 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... AW: It behaves exactly as i expected. Diff is: -----------------<snip>---------------------------- 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(); + if(GetObjectContact().getViewInformation2D().getViewTransformation().isIdentity()) + return drawinglayer::primitive2d::Primitive2DSequence(); + // ignore existing controls which are in alive mode and manually switched to "invisible" // #102090# / 2009-06-05 / frank.schoenheit@sun.com const ControlHolder& rControl( m_pImpl->getExistentControl() ); -----------------<snip>---------------------------- 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 back. 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. works in DEV300.m51, is broken in DEV300.m52 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? - 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... 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 targeting to 3.4, since it has been rejected for 3.3. 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] <frank.schoenheit@sun.com> date: Wed Oct 28 09:50:28 2009 +0100 summary: #i106368# changeset: 264437:2b6c20513ac6 user: Frank Schoenheit [fs] <frank.schoenheit@sun.com> 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 ... 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 ... 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 VCL-Windows. fs->aw: ah, sorry, didn't read from your first comments that the empty transformation is the expected behavior. fixed in CWS dba34b, by committing the preliminary fix suggested by aw. Submitted follow-up issue 115754 for a clean and complete solution. fs->msc: please verify in CWS dba34b 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: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300/dba34b |