Issue 104867 - charts do not update anymore after changes in calc
Summary: charts do not update anymore after changes in calc
Alias: None
Product: General
Classification: Code
Component: chart (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Armin Le Grand
QA Contact: issues@graphics
Keywords: regression
: 105439 106066 (view as issue list)
Depends on:
Blocks: 99999 104769
  Show dependency tree
Reported: 2009-09-07 16:59 UTC by IngridvdM
Modified: 2013-02-24 21:21 UTC (History)
3 users (show)

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

Suggested fix fo this task (7.64 KB, text/plain)
2009-09-10 14:17 UTC, Armin Le Grand
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description IngridvdM 2009-09-07 16:59:27 UTC
Open a spreadsheet. Type some numbers and create a chart.
Leave the chart edit mode.
Change one of the numbers in the spreadsheet.
The chart display should change to visualize the changed data but in dev300m57
it doesn't update anymore.
Comment 1 IngridvdM 2009-09-07 17:08:18 UTC
This has worked in dev300m55 (didn't test m56).
Comment 2 Armin Le Grand 2009-09-10 11:57:40 UTC
AW: On change a new SdrOle2Primitive2D is created from
ViewObjectContactOfSdrOle2Obj. That primitive is compared with the existing one
using SdrOle2Primitive2D::operator==. As a sub-operation (it's a group primitive
containing a SdrOleContentPrimitive2D), SdrOleContentPrimitive2D::operator== is
used. That operator compares the SdrObjectWeakRef mpSdrOle2Obj.
These SdrObjectWeakRefs are equal, so no change is taken. On that level of
comparison, it is not detected that e.g. the MetaFile visualisation may have
changed. I have to think about how this may be checked...
Comment 3 Armin Le Grand 2009-09-10 13:33:13 UTC
AW: Needed is to find out at svt::EmbeddedObjectRef that the Graphic has
changed, but without getting the graphic (which is expensive for chart). Before
SdrOleContentPrimitive2D this happened since the Graphic was always fetched (wat
was the reason for SdrOleContentPrimitive2D).
A possible solution is to check for bNeedUpdate at EmbeddedObjectRef_Impl, but
this will nothelp when anyone else fetched the graphic in-between.
Thus, a graphic version counter which will be incremented each time the graphic
at svt::EmbeddedObjectRef changes and is fetchable, would solve the problem. The
SdrOleContentPrimitive2D would remember the version number at construction time.
In the operator==, it can simply be compared.
Checking if adding such a counter at EmbeddedObjectRef would be difficult...
Comment 4 Armin Le Grand 2009-09-10 14:11:21 UTC
AW: Added a sal_uInt32 mnGraphicVersion member to EmbeddedObjectRef_Impl which
gets inited to 0 and incemented at each change of pGraphic and/or pHCGraphic.
Added a read method to EmbeddedObjectRef. Added a member to
SdrOleContentPrimitive2D whcih is inited at construction time and used for
compare operator.
Works well (and as expected). Doing some more checks, though...
Comment 5 Armin Le Grand 2009-09-10 14:17:57 UTC
Created attachment 64671 [details]
Suggested fix fo this task
Comment 6 Armin Le Grand 2009-09-10 14:19:40 UTC
AW: Added fix as attachment, adding mav to CC.
AW->mav: Since this changes EmbeddedObjectRef in svtools, i keep You informed.
Have a look at the task and the suggested solution if You want.
Comment 7 Armin Le Grand 2009-09-10 14:48:44 UTC
AW: Added to ooo32gsl01
Comment 8 Armin Le Grand 2009-09-15 10:26:46 UTC
AW: Built, unchained (*.link) svx and drawinglayer, checked in, done.
Comment 9 Armin Le Grand 2009-10-16 11:26:28 UTC
AW: Checked in ooo32gsl01, works as expected.
AW->KLA: Please review.
Comment 10 Armin Le Grand 2009-10-16 11:50:51 UTC
AW: I have seen that KLA is on vacation. Since i checked the task and it works,
i will set it back to me and to verified now.
Comment 11 Armin Le Grand 2009-10-16 11:51:13 UTC
AW: Set to verified.
Comment 12 IngridvdM 2009-10-20 10:18:18 UTC
*** Issue 106066 has been marked as a duplicate of this issue. ***
Comment 13 Armin Le Grand 2009-11-24 11:33:10 UTC
AW: Closing.
Comment 14 IngridvdM 2010-02-04 17:40:17 UTC
*** Issue 105439 has been marked as a duplicate of this issue. ***