Issue 19871 - cannot rotate attached object in draw
Summary: cannot rotate attached object in draw
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: OOo 1.1 RC4
Hardware: PC Linux, all
: P4 Trivial (vote)
Target Milestone: OOo 3.1
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-21 23:13 UTC by firmail
Modified: 2009-01-19 09:45 UTC (History)
1 user (show)

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


Attachments
try rotating the triangle to 120 or 240 degrees (6.84 KB, application/octet-stream)
2003-09-21 23:13 UTC, firmail
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description firmail 2003-09-21 23:13:11 UTC
Hi,

I don't know what it is ... but I cannot rotate the blue triangle in the
attached file. I can copy-paste it to another doc and the problem still persists
with this shape.
I have restarted OO - same problem. I have no clue but it seems pretty specific
to  only this shape and only in special rotations.
Try rotating the triangle to 120 degrees or 240. It will be cut of at the sides.

b.
Comment 1 firmail 2003-09-21 23:13:57 UTC
Created attachment 9553 [details]
try rotating the triangle to 120 or 240 degrees
Comment 2 wolframgarten 2003-09-22 08:03:41 UTC
If I understand you right the triangle can be rotated but the edges
are cut of at specific rotation angles. Is this correct? This is
reproducible in a current internal version. Thanks for your help.
Comment 3 firmail 2003-09-22 08:11:39 UTC
Yes, that is more precise. 
Comment 4 wolframgarten 2003-09-22 08:12:55 UTC
Ok,  set to new.
Comment 5 wolframgarten 2003-09-22 08:13:27 UTC
Reassigned to Armin. Please have a look.
Comment 6 Armin Le Grand 2003-09-22 10:07:09 UTC
AW: I have not the slightest idea how this may happen, but it happens.
The object is a polygon object and the angles which show problems are
the ones where the base line of the triangle is horizontal. There must
somehow be a reason why the GetBoundRect from the polygon behaves
different in those cases. I will hae to debug this one.
Comment 7 firmail 2003-09-22 17:01:28 UTC
Have a look at the Glue Point, when I remove it the rotation problem
does not occur (so far)

Comment 8 Armin Le Grand 2003-10-14 13:37:21 UTC
AW: Yes, indeed. It must somehow be caused by the GluePoints. Thus, i
will wait for the necessary GluePoint reworking which then should
influence this problem.
Comment 9 Armin Le Grand 2004-05-07 15:16:43 UTC
.
Comment 10 ooo 2004-12-01 16:35:25 UTC
set to prio4
Comment 11 Armin Le Grand 2005-04-11 16:29:22 UTC
AW: Changed to OOo later.
Comment 12 Armin Le Grand 2008-10-27 15:22:52 UTC
AW: Checked after primitives (aw033). Still the triangle bets the wrong SnapRect
when transformed. Looking for a missing SnapRect invalidation...
Comment 13 Armin Le Grand 2008-10-27 15:29:51 UTC
AW: The SnapRect gets invalidated, but is recalcualted before the geometry data
(the polygon itself) gets changed in SdrPathObj::NbcRotate since first the
parent method - SdrTextObj::NbcRotate - gets called. There, the SnapRect gets
invalidated but also immediately (and wrongly) recalculated in
SetGlueReallyAbsolute(FALSE). I will have to change all svdopath.cxx methods to
first modify locally and then calling the parent methods. Hopefully this will
lose it's relevance once the GluePoints will be defined relative to the object
anyways and lo longer with their crude historical definitions.
Testing...
Comment 14 Armin Le Grand 2008-10-27 15:54:55 UTC
AW: Adapted SdrPathObj::NbcMove, NbcResize, NbcRotate, NbcShear and NbcMirror to
first modify locally and then call parent. Works as expected, checking in. For
the medium run it will be necessary to rework the gluepoint definitions and
handling.
Comment 15 Armin Le Grand 2008-10-27 15:55:21 UTC
AW: Checked in, done.
Comment 16 Armin Le Grand 2008-10-30 18:06:00 UTC
AW: Changing target
Comment 17 Armin Le Grand 2008-11-06 11:13:25 UTC
AW->WG: Please review like described in the task.
Comment 18 wolframgarten 2008-11-17 15:20:16 UTC
Verified in CWS.
Comment 19 wolframgarten 2009-01-19 09:45:38 UTC
Tested in m38. Closed.