Apache OpenOffice (AOO) Bugzilla – Issue 63294
Crash when deleting columns in a chart with column-mapping
Last modified: 2013-02-24 21:21:38 UTC
Create a chart into the Calc. Copy into Impress/Writer Chart inplace Open Datarange by using Kontext Delete all Columns without the first one. Apply by using the Apply-Button. ->crash
Created attachment 34951 [details] Chart with column-mapping
The problem occurs with charts that have a column mapping (see chart:column-mapping attribute in chart:chart element of context.xml stream). Assume having a column mapping e.g. "2 1 0" which means the first and the last series are swapped in their order. If you delete the last data column, the mapping becomes invalid and must be updated. What you get is "<no series> 1 0" which should then become just "1 0". Maybe this update is not done correctly and you get sth. like "2 1" which contains an illegal index to a no-longer-existing third series.
->TK: Changed the subject. Another thing: I couldn't apply a column mapping to a chart any more via the UI (for the bugdoc, I tweaked the file). Do you have an idea when the "Arrangement" context menu entry shows the subentries "Bring Forward" and "Move Backwards"? I thought it was available at least for 3d deep chart types, but couldn't get it anywhere in a OOo 2.0.2. Is this probably broken? Please check.
Addition to the last comment: The Arrangement feature only works for external data. As we are currently limited to getting data from a rectangular region, we have the additional mapping for being able to change the series order. If a chart has its own data, there is no need to use column- and row-mapping. The swap-buttons in the chart data editor really copy the data instead of modifying the mappings. So we only get this bug, when the arrangement of series has been changed in a chart with external data which is then copied, so that it has own data. As said before, the arrangement settings are not used when creating charts with own data. Therefore on copy paste, where data is transfered from an external source to an internal data pool, we should also drop the mapping by applying it to the data.
SchMemChart::UpdateTranslation was completely buggy.
Please verify on sch14. Test with the attached file as well as the internal document where this issue first occured with. re-open issue and reassign to kla@openoffice.org
reassign to kla@openoffice.org
reset resolution to FIXED
verified into CWS sch14
seen ok into the master -> closed