Change versions to AOO340-dev, which is belongs to.

Now really set to AOO340-dev.

Could it be release blocker for 3.4?

*** Issue 119354 has been marked as a duplicate of this issue. ***

Created attachment 77547 [details]
Try to copy chart from this file to another, it will ends in lost data

This is terrible bug. There was something similar in the past, it was not possible to copy charts, where values were ordered in columns or rows, but it was solved long time ago. I think it is unacceptable issue for minor release.

It is relevant also to linux

I tested with my original, bubble and X-Y chart no crash.
No crash with your data under 32bit Win7.

Additionally I tested with 32bit Xubuntu 12.04, and 32 bit opensuse 12.1 with KDE4. No crash for me when inserted chart into drwing, presentation and text documents, all ODF.

Which type of file you used?
Under which version OS 32bit or 64 bit version?

No data point with AOO 3.4 (.deb from website) on Ubuntu 12.04 64bit.

FWIW reverting the commit from the somewhat related bug 118954 doesn't fix the problem. Other than that there were not too many changes in this area since OOo3.4beta.

(In reply to comment #7)
> I tested with my original, bubble and X-Y chart no crash.
> No crash with your data under 32bit Win7.
> 
> Additionally I tested with 32bit Xubuntu 12.04, and 32 bit opensuse 12.1
> with KDE4. No crash for me when inserted chart into drwing, presentation and
> text documents, all ODF.
> 
> Which type of file you used?
> Under which version OS 32bit or 64 bit version?

Hi!

If you mean the attached file, than data are lost during copy from calc to any other OO.o file including calc. Ubuntu 12.04 32 bit. OO.o 3.4

In issue 119177, from Sharo's comment: 
> It's like the default name of first sheet in french ("Feuille1") make the copy of the data not possible.

I can not copy & paste from "Sheet1" but can be from "Sheet2". 
It looks it is the same problem with this.

It seems internal data provider is required to copy the selected chart when 
user copies it. 
I assume Range1 is there on Sheet1 and Range2 is there on Sheet2 in the following comment.

When I copied the chart having Range2 as data range, internal data provider is 
created, but not for the chart bound to Range1 in SchXMLTools::CreateDataSequence method. 
Because xRet.is false in SchXMLTools::CreateDataSequence method. 
lcl_ConvertRange function returns empty string for Range2 but correct string for Range1.  This is caused because of the instance of ScDocument kept by ScChart2DataProvider has 
only Sheet1 (its name is depends on the localization environment). 
The "Sheet1" is required to keep copied drawing object (chart) but it does not have 
data on the sheet, and then NaN is returned for the pasted chart data.

So, how this fix? Please someone take over.

As the side effect of this problem, when I copy and paste chart having its data reference to 
"Sheet2" lose reference to the original range even it is pasted in the same sheet.

I've got a similar problem. Calc x-y charts copy to Writer with the data plot missing.  I notice also that while I can successfully copy and paste the chart to the same or different Calc document, I cannot copy the chart and Paste Special as GDI metafile to even the originating document without losing the data series plot.

Win7 64bit OO 3.4.0 Build 9590 Rev 1327774

strangely i have a few times been able to copy graphs from Calc to Writer without losing the data points, if i restarted the system and tried again, then it would not work.  So it seems that it varies between working and not working depending on some specific conditions.

*** Issue 120613 has been marked as a duplicate of this issue. ***

I get the same problem with 3.4.1.

I confirm this bug for AOO-3.4.1

And as mentioned in comment#11 copying doesn't work from Sheet1

But I mentioned that if Sheet1 is renamed than Copy-Paste function of Chart from Calc to Writer works.
Could anybody confirm such behaviour with remaning of Sheet1 ?

(In reply to comment #18)
> I confirm this bug for AOO-3.4.1
> 
> And as mentioned in comment#11 copying doesn't work from Sheet1
> 
> But I mentioned that if Sheet1 is renamed than Copy-Paste function of Chart
> from Calc to Writer works.
> Could anybody confirm such behaviour with remaning of Sheet1 ?

I can confirm in AOO-3.4.1 windows 7 64 bits with french ui : so 'Feuille1' instead of 'Sheet1'. If you rename 'Feuille1' or copy chart from 'Feuille2', no problem

Even when changing the name of "Sheet1" to something else, I don't get consistent results.  Some graphs will copy properly into a text document, others will copy everything, including the data, but the formatting will be all wrong, and yet for others, the data is just not copied.  Since I update the same graphs week after week, I have found ways to go around this problem.  I'm still using 3.4.1.

This is STILL a problem in 3.4.1!

Whenever I copy a chart from Calc to Writer data ranges disappear or sometimes the chart is completely empty! Too bad but I have to revert to Office.

I can confirm this exact problem on:

A00341m1(Build:9593) - Rev. 1372282
2012-08-13 09:43:38 (Mon, 13 Aug 2012) - Linux i686

en-GB version running on openSuSE 12.2 (i686)

Renaming the sheet, and then copying and pasting seems to solve the problem in this case.

I can confirm this exact problem on OO0-dev 3.5.0 (A00350m1(Build:9611) - Rev. 1400866)

Windows 32-bit version, running under wine 1.5.25 on openSuSE 11.4 (64-bit)

*** Issue 121895 has been marked as a duplicate of this issue. ***

Hi
as this issue is known since AOO 3.4, but still alive in recent dev-snapshots, it seems to be no easy one.

As we learned it is easy to handle by renaming the first sheet from sheet1 to any other stuff. 

So what about adding a space or underscore between name and number in source code, so that users get another name per default, when they open a new spreadsheet? (Sheet 1 or sheet_1, sheet 2 etc.)

If my thoughts are too simplistically – sorry for the noise.

Sorry but this is a regression. It used to work before.
So something has been broken in the new code. Using a workaround is not very elegant and does not fix the root cause that could even worsen in the future with new layers of code.

The good point is that there is a workaround. So better keep this report opened until it's really fixed instead of faking a fix.

*** Issue 122078 has been marked as a duplicate of this issue. ***

*** Issue 122345 has been marked as a duplicate of this issue. ***

ALG: Indeed works when renaming the sheet, strange. Saving does not work (assumed that the cgart data is not added, but linked somehow). Creating a chart in impress, copying to calc, copying back to a new impress works, too. This means the paste-code in the apps is okay, but the copy-code in chart may have a problem.

ALG: Creating chart in Calc filling and selecting some rows/columns, then pressing CTRL-C saves wrong values in SchXMLExport.cxx line 1886 ff, these get wrongly read in SchXMLTableContext.cxx line 782 ff again, once after CTRL-C, also after CTRL-V. Somehow the wrong data source gets to SchXMLExport.cxx SchXMLExportHelper_Impl::exportTable().

ALG: Tried if m_aDataArray in sc is the problem (caching a data line) wuen using ScChart2DataSequence::getNumericalData(), so forced rebuild using m_aDataArray.clear() temporarily; did not help, the newly builded cache has NAN float values and mbIsValue == false. Seems the cache is okay, but somehow the calc data has vanished/the wrong data is accessed.

LO had a similar, now fixed problem in https://bugs.freedesktop.org/show_bug.cgi?id=58562.

A similar problem is described here for Writer tables https://issues.apache.org/ooo/show_bug.cgi?id=103911, with fix in http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/xmloff/source/chart/SchXMLTools.cxx#420

ALG: CHecked again, the only case where the error occurrs is when Calc is the source of the chart. It works when copying to the same calc document. It works copying to other tabs in the same document. It works when initially rename the sheet (before chart creation). It works when renaming the sheet after chart creation. It works when using 'Sheet2' or another existing one from a new calc document.
It does not work when first renaming the sheet, creating chart (copying this works) and renaming back to 'Sheet1'.
It does not work when renaming Sheet1 to Sheetx, Sheet2 to Sheet1, creating chart on formal Sheet2.
There must be some special handling for 'Sheet1'. The most probable scenario is the way of copy/paste is done: A new temporary calc model (TCM) is created and the to-be-copied data is cloned to it. In that TCM the 1st sheet is named Sheet1 (and there is no way to change that). When cloning the chart the test if source and target sheet is the same seems to compare the name which when in source and target is Sheet1 will not clone the chart data since it implies same sheets and thus already existing chart data (DataProvider).
Thus, I will now debug for the part where the chart is cloned to the new temporary model...

ALG: In the current source the cloning happens in two steps:
(1) pObj->Clone();
(2) pNeuObj->SetModel( pNeuMod );

Step (1) clones an SdrOle2Obj to the same model, so does not copy the data of the chart since the DataProvider, the model and the sheet are the same. This is correct and doing something else would make a such cloned chart in calc not listen to it's data in the sheet. This step also saves the chart to a persist stream.

Step(2) then copies the OLE to another model by moving that persist to another model container. Also correct so far.

Both in combination make step (2) miss that the chart data was not copied.

Annotation: in aw080 the relationship between object and model is a life-long, unchangeable operation already, objects can only be cloned *to* a target model. Here this problem would not occur...

As a result, the chart data gets not copied. Checking what could be done to make this work. There is no short, direct way to get away from that two-step cloning process in the current code...

ALG: Indeed the chart uses a temporary ScDocShell/ScDocument combination to be realoaded; when accessing the data range here (e.g. 'Sheet1.A1:Sheet1.A3') it *gets* a data range, but there will be no data (#NAN doubles on next access). There is already a fallback when the range is not accessible which is. e.g. used when the sheet has another name. Thus, another mechanism is needed to know that the ScDocument is a temporary one and contains no useful data. This is possible since the chart implementation creates this temporary ScDocument, thus being able to flag it as such. The request for a range translation can then be answered with an empty string what is correct in that case. Trying out...

ALG: Works as expected. I just stumbled over one case: When copy/pasting in a new calc on Sheet1, the 2nd chart will react on value changes in the sheet. With the fix this will no longer happen since the chart transported over the temporary calc document had created it's own internal data.
On 2nd view this seem correct:
- It is this way with every sheet which is not called 'Sheet1' in the current version
- It may be the exact purpose for the Copy/Paste to detatch the charft from the data, maybe reuse the original, but keep a snapshot with the copy/pasted one
The other cases work as expected, preparing checkin.

ALG: Okay, checked in, done.

*** Issue 119177 has been marked as a duplicate of this issue. ***

*** Issue 120590 has been marked as a duplicate of this issue. ***

I checked in AOO 4.0.0 snapshot build rev 1496831 under windows 8.

working correctly.

Change status to verified.

I checked in AOO 4.0.0 snapshot build rev 1498538 under windows 7 - Don't work.

hello,
as
https://issues.apache.org/ooo/show_bug.cgi?id=119177

Win 8 Pro and MacOsX 10.8.4

with AOO 4.0.0 buid 9702 rev 149 347

working correctly

Thanks

I checked in AOO 4.0.0 build 9702 rev 1503704 under windows 7.

working correctly.

The fix has to be rejected because it seems to cause Issue 122897?