Losing Chart Data Series-3.0 bug?

[_j_]

I have a chart where I have created a set of data series under the "data series" tab in the "data range" box. For nearly two years now once a week I change the data range in the data range box to chart additional data. This week when I try to change the date range I lose my group of items in the data series box. I have not been able to find away to prevent this and after numerous times reopening the file, where I still have my data *series*, in attempts to find a solution. I upgraded to 3.0 right as it was coming out. My first attempt to change this under 3.0 worked the same as usual, but I am wondering if perhaps now that I have *once* saved the file under 3.0 that perhaps this could still be a bug. It would be a real pain to have to reenter these series each week. Any comments or ideas on what may be going on?

[_j_]

I have done additional testing and was able to repeat this behavior *exactly* on a version of the file that I had backed up months ago but had not yet *saved* in 3.0. Any change anywhere in the range will cause the series loss. I can select even just one character and type in the exact same character in the data range and this will occur. This leaves me to think that, unless something has changed in the way that you are supposed to identify cells in 3.0's format, that this is most likely a bug.

[acknak]

Are your data stored in the spreadsheet, or in the chart itself?

Are you actually losing data, or are you just losing the data series configuration?

Either way, it would be really helpful if you can report your problem in the OOo issue tracker, especially if you can attach your file and the exact instructions for reproducing the series loss.

See [Tutorial] Reporting bugs or suggestions for more information.

[_j_]

The chart calls all data from the spreadsheet. I am not losing data (from spreadsheet) just the four manually added "data series" items (called from spreadsheet) that I added when I originally created the spreadsheet. If I have time tomorrow I will try to see if added data series items are lost if I simply enter some data series items in 3.0 and then save as 3.0; I am wondering if this will even work. I cannot attach the file; it is very large and with private information in it. I would try to reproduce the original 2.x to 3.0 issue in another file but I will have to find time to find and download 2.x again. BTW, I have tried changing the data save format option away from 3.0 to the old format, but this doesn't help, it appears that it is lost in the 3.0 save transaction. I may be able to simplify further, but the issue thus far appears to be as simple as saving a file from 2.x with self added data series as a 3.0 file. Here is my main data *range* formula that I can't edit without losing my "data series" items. See anything peculiar that I have done that may be causing the issue with 3.0? I get no error message.

Data range formula 2008 is the sheet name.
$'2008'.$A$3:$A$204;$'2008'.$BW$1:$BW$204;$'2008'.$CA$1:$CA$204;$'2008'.$CE$1:$CE$204;$'2008'.$CG$1:$CG$204

I thought about reporting this as a bug earlier today but got busy. I will try to report tomorrow.

[_j_]

I tried to reproduce this with a new small spreadsheet in 3.0 and saving in 3.0 and was not able; it seems to work right.
I tried using *my* 2.x file in 3.0 and saving in 2.x format and this did not help. Once my file is saved in 3.0, regardless of format the issue will occur. Is there an openoffice originating link where I can download the last 2.x version to see if the issue will occur if I create a sample file in 2.x and then save in 3.0?

[TheGurkha]

You can get older versions from here FileHippo.

[_j_]

The program is changing data ranges after saving in 3.0, and this is what is causing the series losses. I noticed this when messing in 2.1. Here is an example from my data in 2.x, changing data in 3.0 and saving, and then a third reopen with changed values.
original-$'2008'.$A$2:$A$209;$'2008'.$BW$1:$BW$209;$'2008'.$CA$1:$CA$209;$'2008'.$CE$1:$CE$209;$'2008'.$CG$1:$CG$209
my first change-
$'2008'.$A$2:$A$208;$'2008'.$BW$1:$BW$208;$'2008'.$CA$1:$CA$208;$'2008'.$CE$1:$CE$208;$'2008'.$CG$1:$CG$208
after 3.0 save change-$'2008'.$A$3:$A$208;$'2008'.$BW$1:$BW$208;$'2008'.$CA$1:$CA$208;$'2008'.$CE$1:$CE$208;$'2008'.$CG$1:$CG$208
It doesn't always take the same format either. Sometimes it makes a change and adds ;$'sheetname'.$A$1 , sheetname being whatever the sheetname is, to the end of the data. This in fact is how I found it when I tried opening the 3.0 saved file in 2.1. And in tests where I was able to reproduce this in new files. In the example below I get these result on the attached file that I created in 2.1 earlier today. It is still a working chart because of where the variables wind up but you can see that 3.0 saving, and independent of save format, is causing changes. These changes also repeat on each subsequent reopen with further changed cell calls.

$'2009'.$A$2:$B$5;$'2009'.$B$1:$B$5;$'2009'.$D$1:$D$5;$'2009'.$F$1:$F$5;$'2009'.$A$1
$'2009'.$A$2:$B$4;$'2009'.$B$1:$B$4;$'2009'.$D$1:$D$4;$'2009'.$F$1:$F$4;$'2009'.$A$1
$'2009'.$A$1:$B$5;$'2009'.$D$1:$D$5;$'2009'.$F$1:$F$5


Also, something I noticed again that I noticed after installing 3.0 the first time, it changes my default 2.1 line chart line width from .00 to .03 after saving in 3.0.

[acknak]

Sorry, I don't understand what I should look for in your sample document.

... it changes my default 2.1 line chart line width from .00 to .03 after saving in 3.0.

I'm fairly sure I saw somewhere that this was done purposely because ".00" means "one pixel" thick, which is way too thin on most printers.

[_j_]

To start with let me add, though I am not positive, I believe that the file may also show an example of how sometimes you wind up with the added ;$'2009'.$A$1 on the end. I don't really see the purpose here and imagine that it may be as has been in other places where 3.0 *seemingly* add or moves this from the formula, but like I say, I am not positive that this wasn't my exact formula when I was running 2.1 yesterday.

Moving on... If you take aa2x.ods and say change all the 5's in the data range to 4's, thereby moving the column up, and then save it as a new file you wind up with the new file that I have attached called aa2x2.ods. If you then close the file, reopen and change all of the 4's back to 5's and then save it to a new file you wind up with the new file that I have attached called aa2x3.ods. You will see changes to the data range in this last file. It is not necessary in this example however to save the file a third time to see the change occuring. Merely click on the data series tab and back to data range and it will make the change then.

Regarding the change of line thickness from .00 to .03, perhaps these unrequested changes of file settings upon upgrading is having effects elsewhere also. Don't know if this is the case or how the code is written, but it seems to me that the .00 setting should have been saved in the .00 document allowing 3.0 to open and therefore save with that original setting.


Edit: I see that the third file is not showing the change after saved. These aren't the files I saved yesterday, which are gone, but from today. I will respond later.

[_j_]

Apparently 3.0 may be attempting to correct what it *assumes* is an error in the data start points. This does not occur in previous versions. I think that the issues has to do with the fact the data in column A and column B do not start in the same spot in the attached example cc.ods, and 3.0 is attempting to correct this. If you change all of the 6's in the file cc.ods data range

$'2009'.$A$2:$A$6;$'2009'.$C$1:$C$6;$'2009'.$E$1:$E$6;$'2009'.$G$1:$G$6

to 5's

$'2009'.$A$2:$A$5;$'2009'.$C$1:$C$5;$'2009'.$E$1:$E$5;$'2009'.$G$1:$G$5

then click ok, save, close, and restart
you will end up with a working chart *until you change the data range.* But notice that because 3.0 has changed the data range already to

$'2009'.$A$3:$A$5;$'2009'.$C$1:$C$5;$'2009'.$E$1:$E$5;$'2009'.$G$1:$G$5

as shown in the attached example cc2.ods, if $'2009'.$A$3 is not corrected the chart will no longer work.

The solution to this is to change $2009/$A$3 back to $2009/$A$2

[_j_]

Also, I notice that each time you correct the data range and click ok, it sends a continually corrected .00 line width back to .03

I opened a bug report yesterday.
http://qa.openoffice.org/issues/show_bug.cgi?id=95515

Edit: spelling,grammar

[acknak]

Sorry, I still don't see what you're seeing.

Here's what I did:
1) File > Open > cc.ods
2) Double-click the chart
3) Format > Data Ranges > Data Range
3) Manually change all the ranges ending at row 6 to row 5:
$'2009'.$A$2:$A$5;$'2009'.$C$1:$C$5;$'2009'.$E$1:$E$5;$'2009'.$G$1:$G$5
4) File > Save As cc_edit.ods
5) File > Close
6) Exit/Restart OOo
7) File > Open cc_edit.ods -- looks ok
8) Change "b" range from $C$1:$C$5 to $C$1:$C$4 or $C$1:$C$6

That all seems to work fine for me.

Is that the correct set of steps to see the problem?

[Cambirder]

Yes I can replicate this odd behavour. As you say it does not happen if you start everything in row 1. I doubt whether this would effect too many people as most of us would indeed start everything in the same row, as in the example you have posted there is no logical reason to do other wise.

[acknak]

Maybe this is something peculiar to the Windows build? Or maybe I don't have the right steps.

[_j_]

That all seems to work fine for me.

Is that the correct set of steps to see the problem?

Omit step 8 and reopen and see that the data range has changed...

$'2009'.$A$2:$A$6;$'2009'.$C$1:$C$6;$'2009'.$E$1:$E$6;$'2009'.$G$1:$G$6

has been changed to

$'2009'.$A$2:$A$6;$'2009'.$C$1:$C$6;$'2009'.$E$1:$E$6;$'2009'.$G$1:$G$6

Maybe this is something peculiar to the Windows build? Or maybe I don't have the right steps.

I am in the process of updating Fedora 9. I will test there when I am finished.



Edit: spelling, grammar, removed response to Cambirder...haven't tested implications.

[_j_]

The most recent update that Fedora picks up from the repository is 2.4.1 If this is what you are using, remember the issue only occurs in 3.0

[Cambirder]

Maybe this is something peculiar to the Windows build? Or maybe I don't have the right steps.

No, I managed to replicate it under Linux.