Issue 119287 - Shadow is not applied to chart initially.
Summary: Shadow is not applied to chart initially.
Status: CLOSED FIXED
Alias: None
Product: Draw
Classification: Application
Component: ui (show other issues)
Version: version58
Hardware: PC Windows 7
: P3 Normal (vote)
Target Milestone: 4.0.0
Assignee: Armin Le Grand
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-25 12:45 UTC by ImSoftwareSystems
Modified: 2014-07-10 13:57 UTC (History)
4 users (show)

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


Attachments
Shadow not applied to chart. (24.15 KB, image/pjpeg)
2012-04-25 12:45 UTC, ImSoftwareSystems
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description ImSoftwareSystems 2012-04-25 12:45:28 UTC
Created attachment 77493 [details]
Shadow not applied to chart.

Select Drawing application => Create a star from "Stars" => Place chart from the tool bar =>Select star => From context menu, select "Edit Style" => Select Shadow tab => Select "Use Shadow" => Click on "OK".

Shadow is applied only to star but not chart where as it is expected but If the chart is selected,line is selected from the context menu and line style is changed then the shadow is applied to chart.
Comment 1 Armin Le Grand 2012-04-25 13:02:28 UTC
ALG: Ole objects (chart in this case) seem to have the style not correctly initialized. When pressing F11 (style and formatting) and vice-versa selecting star or OLE it displays the style the object has.
When selecting OLE and then double-klicking on Default in the F11 view the OLE gets the style and all further actions (e.g. changing the style) work as expected.

I will need to check initial state of style for OLE (and of inserted graphics, seems to be the same case).
Comment 2 Armin Le Grand 2012-04-25 13:09:56 UTC
ALG: Has to do with default formatting: Using format/default_formatting from the menu will make styles work for chart and graphics. This means that for these object types initial hard attributes are set.

And yes, there are hard attributes set. This was necessary since in older OOo versions OLE and graphics were not able to have styles (line, fill, etc.) but internally used the default fill style. This means all ever created OLE and graphic are by default filled, but it was never visualized. This is corrected at load time (old OLE and graphic get fill set hard to none) and at construction time.

The only way I see to change this would be to have an extra graphics default style for OLE and graphic objects. I will have to think about the implications of doing this...
Comment 3 Armin Le Grand 2012-05-31 10:38:42 UTC
ALG: createNewSdrLineFillShadowTextAttribute (used in primitive creation) needed to check for shadow not only when there is text or fill or line, but also when there is content, in the cases of OLE and graphic objects. This was already implemented as exception for graphic object, but not for OLE. Unified these approaches and named it more clearly.
Investigating in a possible style 'NoLineNoFill' to avoid setting hard attributes for line and fill for OLE and graphic objects...
Comment 4 Armin Le Grand 2012-05-31 14:21:55 UTC
ALG: Removed hard attribute setting at OleProperties::ForceDefaultAttributes and GraphicProperties::ForceDefaultAttributes to allow a style to 'shine through' with his fill and line style. To still create valid OLE and graphic objects I added a new default style NoFillNoLine which these get initially and which has the style 'Default' as parent. This allows to change e.g. the shadow of the default style and have all objects (including OLE and GraphicObject) use it (same with fill and line). The principle is: as less hard attributes as possible.
Checked save/load cycle, exchange with OOo3.3 and others, works well.
Comment 5 Armin Le Grand 2012-05-31 14:24:09 UTC
ALG: Okay, done. Comitted to trunk with r1344740.
Comment 6 Armin Le Grand 2012-06-08 17:09:11 UTC
ALG: Reopening, e.g. convert ellipe to bitmap/metafile creates SdrGrafObj, but with default attributes. This needs to be adapted. All in all constructors for SdrGrafObj and SdrSdrOle2Obj need to be checked more carefully.
Comment 7 Armin Le Grand 2012-06-11 11:49:47 UTC
ALG: Need another approach, the StyleSheet needs to be in place at all Ole/Graphic objects in principle. To do so, it's very sad that aw080 is not done yet; there the SDrObjects have a SDrModel at creation time and could be inited there. For the current office I need a compromize. It is good to use ::SetPage(), better as ::SetModel() which would be good but will collide with aw080 definitely. To not risk to loose this change in aw080, I put it to SetPage() and make comments for aw080 there (TTTT is my temporary tag for aw080 todos). Building and testing...
Comment 8 Armin Le Grand 2012-06-11 15:55:20 UTC
ALG: Works as expected, including burn in for StyleSheetAttributes when transfering. Done.
Comment 9 louqle 2012-06-18 06:27:29 UTC
verified in r1350879
Comment 10 liuping 2012-06-25 06:10:19 UTC
confirm fixing the bug on ver 1351249 in Win7 ,pass
Comment 11 SVN Robot 2014-07-09 12:07:29 UTC
"alg" committed SVN revision 1609118 into trunk:
i119287 corrected default style for draw objects created using UNO API
Comment 12 Armin Le Grand 2014-07-09 12:45:44 UTC
Please ignore comment 11, I used the wrong Issue ID in the commit, sorry. Task for this commit was Issue 125222.
Comment 13 SVN Robot 2014-07-10 13:57:47 UTC
"alg" committed SVN revision 1609460 into branches/AOO410:
i119287 corrected default style for draw objects created using UNO API