expected: in an existing chart the user can decide which should be the end of the data range, even if there empty cells in the selected range. application example for this: monitoring a running measuring system which provide additional data every 20 s. New data added by manual copy and paste via Notepad++ from the first data on. There are some charts for different parameters to monitor at the same time. how to reproduce: create an (x-y-scatter)chart for some filled cells e.g. A1:B5 select data row x extend the range beyond the filled cells, e.g. to A10 or more the range will be shortened by calc nearly immediately after the input, if not before then at the time when you switch to the y-range to extend the range this regression is true for all relases newer then LibreOffice 3.4.6 this behaviour is mentioned in Bug 47593 as point A
If I consider the test file from bug 47593 (https://bugs.freedesktop.org/attachment.cgi?id=58765), I think there is an easy workaround: 1/ set maximum for X and Y axis as automatic 2/ create a virtual last value for the chart 3/ add new values before the last one instead of after by inserting new cells 4/ if needed modify the X-value of the last virtual data point to extend the X-range. Best regards. JBF
O.K. Testing the workaround with LO portable 3.6.1.1 and set the dummy value behind the chart range works. But let me try to explain my problem with this workaround: Sorry I can't upload an example file because they contain customer data. Last week I got a file with more than 12000 data rows in twelfe columns. Three diagrams with secondary y-axes for monitoring purposes of the system contain all data. The measuring values are obtained calculating the slope of a mass against the cumulated volume. One chart per one measuring condition, that means a growing number of charts in one ods-file. In this case using dummy values is dangerous. Because of that I had to stay with LO 3.4.6 at home pc and measuring computers. On my workplace pc I use the newest release, because there are no such growing data volumes to handle. Best regards, ch
Thanks for the workaround. This bug has been driving me mad for months.
I can confirm this bug in Version 3.6.3.2 (Build ID: 58f22d5).
argln, we suffered from this bug for years and couldn't figure out what's the reason until i found this bug report. using a dummy value works too but that bug should really be fixed because it's very hard to track this down. we're using calc for shopping lists with autofilter. of course some items won't have any numbers in front of them and calc then changes the data range :(
(In reply to comment #5) > argln, we suffered from this bug for years and couldn't figure out what's > the reason until i found this bug report. using a dummy value works too but > that bug should really be fixed because it's very hard to track this down. > > we're using calc for shopping lists with autofilter. of course some items > won't have any numbers in front of them and calc then changes the data range > :( sorry for replying to myself. this bug ends up in a logical problem in our usage. we use autofilter for empty/non-empty in column A to show/hide rows in column B. this can't work if anything empty is removed from the data range.
Hallo. Testing with the new releaese 4.0.0.3 (portable apps build)gives the same result as in all LO 3.5.x through 3.6.5 releases: the bug persists. Because of that, I set the keyword "regression". I forgot that in october. Since release 3.5.0 all users, which handle with growing data amounts in data sheets and charts, like measurement values and statistics are sidelined from the progress of LO. Exept users, which can apply the workaround from Jean-Baptiste. Best regards, ch
This is related to the fix of Bug 39847
*** Bug 47593 has been marked as a duplicate of this bug. ***
I have found, that in Release 4.1.1.2 the bug is still existant. I also think it should be fixed asap!!
Improvements for this problem have been pushed as part of Bug 70609. Proper algorithm still needs some time.
(In reply to chemist56 from comment #7) > Hallo. Testing with the new releaese 4.0.0.3 (portable apps build)gives the > same result as in all LO 3.5.x through 3.6.5 releases: the bug persists. > Because of that, I set the keyword "regression". I forgot that in october. > Since release 3.5.0.. Bug predates start of bibisect, so Whiteboard -> notBibisectable
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.