Bug 55697 - impossible to define data ranges beyond actual filled cells
Summary: impossible to define data ranges beyond actual filled cells
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
: 47593 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-10-06 16:12 UTC by chemist56
Modified: 2020-06-10 09:30 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description chemist56 2012-10-06 16:12:31 UTC 
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
Comment 1 Jean-Baptiste Faure 2012-10-07 08:01:22 UTC 
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
Comment 2 chemist56 2012-10-07 11:58:42 UTC 
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
Comment 3 Tony 2012-10-27 11:49:14 UTC 
Thanks for the workaround.  This bug has been driving me mad for months.
Comment 4 Michael Crouch 2012-11-12 18:12:06 UTC 
I can confirm this bug in Version 3.6.3.2 (Build ID: 58f22d5).
Comment 5 aru 2012-11-17 22:54:47 UTC 
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 :(
Comment 6 aru 2012-11-17 23:04:56 UTC 
(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.
Comment 7 chemist56 2013-02-17 18:47:23 UTC 
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
Comment 8 Markus Mohrhard 2013-03-18 18:05:32 UTC 
This is related to the fix of Bug 39847
Comment 9 Markus Mohrhard 2013-05-06 15:43:38 UTC 
*** Bug 47593 has been marked as a duplicate of this bug. ***
Comment 10 Joachim Manke 2013-09-10 06:33:10 UTC 
I have found, that in Release 4.1.1.2 the bug is still existant. I also think it should be fixed asap!!
Comment 11 Markus Mohrhard 2014-04-17 01:01:35 UTC 
Improvements for this problem have been pushed as part of Bug 70609. Proper algorithm still needs some time.
Comment 12 Robinson Tryon (qubit) 2015-01-19 06:41:05 UTC 
(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
Comment 13 Robinson Tryon (qubit) 2015-12-10 01:26:30 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2017-01-03 19:40:30 UTC Comment hidden (obsolete)
Comment 15 chemist56 2017-04-16 18:07:50 UTC 
Works for me. LO 5.2.6 x86/x64 on Windows 7, 8.1, 10.

Please have a look at comment 11 from Markus Mohrhard.

Best regards Ch