MRU->BM: is it really necessary to set the document "modified" when an chart
object from an OO1 document  is opened? It does not matter wether it is opened
in OO 1.x or OO 2.0.x; both show the same behaviour.

Re-assigning to the Chart component - this also occurs for .ods files with a 3D
chart (it turns out) having cut this down yet further.

Created attachment 36675 [details]
almost empty spreadsheet

seems it affects even simple, non-3D charts.

So - some traces from here:

Chart::SetModified 1 (can set? 1)
#0  SchChartDocShell::SetModified (this=0x8ac0158, bModified=1 '\001') at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:465
#1  0xaf5d3f47 in ChartModel::SetChanged () at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:203
#2  0xaf5b95d0 in ChartModel::BuildChart () at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:203
#3  0xaf5bc0e9 in ChartModel::SetChartDataBuffered () at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:203
#4  0xaf5edaf9 in SchUpdate () at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:203
#5  0xb1b4ca4b in SchDLL::Update () from ./libsc680li.so
#6  0xb18d3d16 in ScDocument::UpdateChartListenerCollection (this=0x8947140) at
/opt/OpenOffice/OOO_2_0_2/sc/source/core/data/documen5.cxx:623
#7  0xb16695f2 in ScDocShell::SetDrawModified (this=0x8947108, bIsModified=1
'\001') at /opt/OpenOffice/OOO_2_0_2/sc/source/ui/docshell/docsh.cxx:2300
#8  0xb1669721 in ScDocShell::SetDocumentModified (this=0x8947108, bIsModified=1
'\001')
    at /opt/OpenOffice/OOO_2_0_2/sc/source/ui/docshell/docsh.cxx:2243
#9  0xb1669a40 in ~ScDocShellModificator (this=0x89c9230) at
/opt/OpenOffice/OOO_2_0_2/sc/source/ui/docshell/docsh.cxx:2393
#10 0xb166e105 in ScDocShell::AfterXMLLoading (this=0x8947108, bRet=1 '\001') at
/opt/OpenOffice/OOO_2_0_2/sc/source/ui/docshell/docsh.cxx:621
#11 0xb166e207 in ScDocShell::LoadXML (this=0x8947108, pMedium=0x895e340,
xStor=@0xbfa2bb1c)
    at /opt/OpenOffice/OOO_2_0_2/sc/source/ui/docshell/docsh.cxx:652
#12 0xb166fd5d in ScDocShell::Load (this=0x8947108, rMedium=@0x895e340) at
/opt/OpenOffice/OOO_2_0_2/sc/source/ui/docshell/docsh.cxx:705
#13 0xb31e27f1 in SfxObjectShell::LoadOwnFormat () from ./libsfx680li.so
#14 0xb31e5cb3 in SfxObjectShell::DoLoad () from ./libsfx680li.so
#15 0xb3218606 in SfxBaseModel::load () from ./libsfx680li.so
#16 0xb32356fe in SfxFrameLoader_Impl::load () from ./libsfx680li.so
#17 0xb2e04a03 in framework::LoadEnv::impl_loadContent () from ./libfwk680li.so

This (almost certainly wrong ;-) patch stops the problem, but no doubt breaks
tons of other stuff - perhaps by re-using that chart in a writer doc. I can see
if it is in fact in the chart component instead.

RCS file: /cvs/sc/sc/source/ui/docshell/docsh.cxx,v
retrieving revision 1.83
diff -u -p -u -r1.83 docsh.cxx
--- docsh.cxx   27 Jan 2006 15:51:57 -0000      1.83
+++ docsh.cxx   23 May 2006 13:06:01 -0000
@@ -614,6 +618,7 @@ void ScDocShell::AfterXMLLoading(sal_Boo
                aDocument.SetInsertingFromOtherDoc( FALSE );
 
        aDocument.SetImportingXML( FALSE );
+       SetDocumentModifiedPending( FALSE );
     bIsEmpty = FALSE;
 
     if (pModificator)

Interestingly, if the chart is self-contained; ie. doesn't get it's data from a
spreadsheet - then (apparently) there is no problem.
So perhaps the proposed 'fix' is not -so- far-fetched :-)

Well, resetting the DocumentModifiedPending may cure the symptom, but I'd rather
like to find the cause instead. And yes, resetting that may even hurt.

Bjoern, AFAIR we needed some mechanism for OOo1.x charts to replace the SomeData
and things with valid source range sequences, and have them modified in case
they're swapped out again, or copied via clipboard. Unfortunately embedded
object's implementation changed completely in the meantime and 'mav' commented
out quite some portions of the old code in Calc, so that may be related.
Wouldn't directly explain the same behavior in Writer though, unless similar
workarounds were provided there. Any insight?

good point - I had simply assumed that this was becuase calc was being used for
the writer case - but in fact, not so (apparently). So this does belong with
'chart' the writer traces for the (final 4 efficatious) SetModified calls are
all children of:

#0  SchChartDocShell::SetModified (this=0x8b8a9f8, bModified=1 '\001') at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:465
#1  0xb31812c7 in SfxObjectShell::SetVisArea () from ./libsfx680li.so
#2  0xaef67032 in SchChartDocShell::SetVisArea (this=0x8b8a9f8,
rRect=@0xbffe96c0) at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:413
#3  0xb31707e5 in SfxBaseModel::setVisualAreaSize () from ./libsfx680li.so

eg.

#4  0xaf797060 in DocumentHolder::SetExtent () from ./libembobj.so
#5  0xaf791902 in OCommonEmbeddedObject::setVisualAreaSize () from ./libembobj.so
#6  0xb1a8ccaa in SwWrtShell::CalcAndSetScale () from ./libsw680li.so
#7  0xb1645687 in SwCntntNotify::~SwCntntNotify () from ./libsw680li.so
#8  0xb172b044 in SwNoTxtFrm::MakeAll () from ./libsw680li.so
#9  0xb162c4bf in SwFrm::OptPrepareMake () from ./libsw680li.so
#10 0xb164fccd in SwFrm::OptCalc () from ./libsw680li.so
#11 0xb164cf41 in SwLayAction::_FormatCntnt () from ./libsw680li.so
#12 0xb164fae3 in SwLayAction::_FormatFlyCntnt () from ./libsw680li.so
#13 0xb1654efd in SwObjectFormatter::_FormatObj () from ./libsw680li.so
#14 0xb1655b99 in SwObjectFormatterTxtFrm::DoFormatObj () from ./libsw680li.so
#15 0xb1654d7f in SwObjectFormatter::_FormatObjsAtFrm () from ./libsw680li.so
#16 0xb1655945 in SwObjectFormatterTxtFrm::DoFormatObjs () from ./libsw680li.so
#17 0xb1654c18 in SwObjectFormatter::FormatObjsAtFrm () from ./libsw680li.so
#18 0xb164d14a in SwLayAction::FormatCntnt () from ./libsw680li.so
#19 0xb164ebfc in SwLayAction::InternalAction () from ./libsw680li.so
#20 0xb164f20b in SwLayAction::Action () from ./libsw680li.so
#21 0xb15829ad in ViewShell::ImplEndAction () from ./libsw680li.so
#22 0xb155df05 in ViewShell::EndAction () from ./libsw680li.so
#23 0xb156655a in SwCrsrShell::EndAction () from ./libsw680li.so
#24 0xb1a78ed7 in SwView::OuterResizePixel () from ./libsw680li.so
#25 0xb31a1433 in SfxViewFrame::DoAdjustPosSizePixel () from ./libsfx680li.so
#26 0xb31a52d7 in SfxViewFrame::Resize () from ./libsfx680li.so
#27 0xb31a9dce in SfxTopViewWin_Impl::Resize () from ./libsfx680li.so
#28 0xb7e70986 in Window::ImplCallResize () from ./libvcl680li.so
#29 0xb7e71d85 in Window::ImplPosSizeWindow () from ./libvcl680li.so
#30 0xb7e71ce5 in Window::ImplPosSizeWindow () from ./libvcl680li.so
#31 0xb7e725dc in Window::SetPosSizePixel () from ./libvcl680li.so
#32 0xb7e79497 in Window::SetPosSizePixel () from ./libvcl680li.so
#33 0xb319090c in SfxFrame::SetToolSpaceBorderPixel_Impl () from ./libsfx680li.so
#34 0xb30d27da in SfxFrameWorkWin_Impl::ArrangeChilds_Impl () from ./libsfx680li.so
#35 0xb31939b3 in SfxFrame::Resize () from ./libsfx680li.so
#36 0xb31a9c4b in SfxTopWindow_Impl::DoResize () from ./libsfx680li.so
#37 0xb31a9c87 in SfxTopWindow_Impl::Resize () from ./libsfx680li.so
#38 0xb7e70986 in Window::ImplCallResize () from ./libvcl680li.so
#39 0xb7e70d3a in Window::Show () from ./libvcl680li.so
#40 0xb31a592d in SfxViewFrame::Show () from ./libsfx680li.so
#41 0xb31ac1e4 in SfxTopFrame::InsertDocument () from ./libsfx680li.so
#42 0xb3147d7c in SfxObjectShell::LoadWindows_Impl () from ./libsfx680li.so
#43 0xb31abce8 in SfxTopFrame::InsertDocument () from ./libsfx680li.so

with eg.

#1  0xaef66ed1 in SchChartDocShell::SetModified (this=0x8b8a9f8, bModified=1 '\001')
    at /opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:464
#2  0xaef1ff47 in ChartModel::SetChanged () at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:203
#3  0xaef055d0 in ChartModel::BuildChart () at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:203
#4  0xaef06212 in ChartModel::ResizePage () at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:203
#5  0xaef671fe in SchChartDocShell::SetVisArea (this=0x8b8a9f8,
rRect=@0xbffe96c0) at
/opt/OpenOffice/OOO_2_0_2/sch/source/ui/docshell/docshel1.cxx:436
#6  0xb31707e5 in SfxBaseModel::setVisualAreaSize () from ./libsfx680li.so

Just noticed that in the new chart when activating the chart, the model gets a
call to setVisualAreaSize() where a size of 1/100 mm bigger in both extents,
which also leads to a modification -- strange ... But at least this is the only
problem. When this call does not modify the model, the disk symbol stays
disabled and closing leads to no dialog.

<bm_> Hum ...
<bm_> If the problem is really the different units in XML, this seems to be a
problem. These are the values in the bugdoc:
<bm_> chart: 6.5087, frame: 6.509448818897638
<bm_> chart: 5.0091, frame: 5.009842519685039
<bm_> ... in inches. So this is a rounding problem
...
<bm_> I thought we changed the units from centimeters to inches at all places
from the old format (.sxc) to the new one (.ods). Whenever an old document is
loaded and saved in the new format it must be loaded and converted. So maybe
there is a bug in the transformation (xmloff/transform)

Setting target to 2.0.4.  This should be fixed also in the current chart, as it
is quite an annoyance.

Ok, the transfomation does NOT convert "in" to "cm" (or the other way round),
but "inch" to "in". It was just a correction of the unit text.
Which unit is used to export a file is determined by the application's language
settings. So, if you create a Calc containing a Chart with settings to "in", you
will get all sizes in inch. If you load such a file in a version with "cm" as
unit and change some cell content that does not affect the chart, you will get
"cm" in the Calc's content.xml stream. As the chart was unchanged, you will
still have the "in" inside the chart.
If you have rounding errors, then you will get the modification state.
To solve this problem, we should reset modification in case the chart is just
loaded, which might not be that easy because a chart is only loaded
(automatically) when it becomes visible.

One open question: Why is the document modified immediately in the bugdoc. One
idea: it IS 3d, because there was a problem with replacement images in 3d, which
are bitmaps, when loading a document in high-contrast mode. Maybe 3d-charts are
always loaded. Have to check ...

Still no Idea. Setting target back to 2.x

Changing target in addition to the comment :-/

Just noted, that the issue does not appear in the new chart, but this might be
due to a missing update notification after loading of charts. (If this is the
reason, there is a wrong update call from Calc that leads to the modified state).

After the chart is loaded (and its modified state is reset to false), the method
ChartModel::setVisualAreaSize() is called from sw with a slightly different
size. Before: (12475, 8476), new size: (12473, 8475). This leads to a modified
state. And again with (12472, 8475).

Maybe the size in the file is simply broken, maybe the setting of the new size
should be followed by a setModified(false), if it is clear that this is just
setting the size directly after loading.

move to target 3.x according http://wiki.services.openoffice.org/wiki/Target_3x

change owner

reset to new

The wrong modified state after load of the attached example document
'modonload.ods' was fixed already with the new charts implementation since OOo 2.3.
Writer documents may behave different because the writer might slightly replace
and resize his OLE objects during its layout process.
The given link is not valid anymore so I cannot check with the writer document.
If you encounter a problem with writer documents still please create a new issue
and attach an example document.
This issue already has to much outdated stuff in it. Better to start clean
again, if there is something left.
Thanks!

closing