Bug 45502 - FORMATTING: Using the Fill handle on cells with dashes counts down, not up, and removes dash
Summary: FORMATTING: Using the Fill handle on cells with dashes counts down, not up, a...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: AutoFill
  Show dependency tree / graph
 
Reported: 2012-02-01 06:55 UTC by Jon
Modified: 2018-10-14 06:35 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Example of when the fill handle counts backwards and removes the dash. (30.18 KB, image/jpeg)
2012-02-01 06:55 UTC, Jon 		Details
Sample document (10.19 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-02-01 07:46 UTC, Rainer Bielefeld Retired 		Details
View All 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 Jon 2012-02-01 06:55:30 UTC 
Created attachment 56452 [details]
Example of when the fill handle counts backwards and removes the dash.

Problem description: 

Steps to reproduce:
1. Type 123456-0001 into any cell
2. Use the fill handle to fill a series down

Current behavior:
The number displayed in the second cell is 1234560000.  It is removing the dashes from all subsequent cells as well.  It also seems as if it is treating the original number 123456-0001 as a subtraction to get the next cell.  Then it proceeds to add to the following numbers. If you start with 123456-0002 and fill down, the second cell contains 123456-0001, then from the third cell it continues as before.  It will always count down until it hits -0000, in which case it removes the dash.

Expected behavior:
The filled cells should be adding to the first cell, without removing the dash.  For instance, if I place 123456-0001 in the first cell and fill down, the second cell should contain 123456-0002 and so on.

Platform: Windows 7 HP 64
              
Browser: Chrome/16.0.912.77
Comment 1 Rainer Bielefeld Retired 2012-02-01 07:46:32 UTC 
Created attachment 56454 [details]
Sample document

The current behavior is rather unforeseeable. OOo 3.1.1 handles all inputs as strings (what seems consequent for me), OOo 3.3 and LibO (I tested 3.3.0, I believe, inherited from OOo) does that strange behavior. For me that looks like a bug, but I don't know.
Comment 2 Rainer Bielefeld Retired 2012-02-08 21:29:13 UTC 
[Reproducible] with "LibreOffice 3.5.0 RC3 German UI/Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit).

From <discuss@de.libreoffice.org> I received the hint that in 'Sample 2012-02-01 15:46 UTC, Rainer Bielefeld'  in Column "Copy paste from Bug report" the string has some tailing blanks, what cause the different behavior from Column A and Column B. So the problem has been reduced to the one from original report and sample. 

Fill handle should work on first substring recognized as number as shown in columns D ... F, current behavior IMHO is wrong.

I did some tests with 2 simple string "100-10" and also "100 10", here the fill handle results!

Reference OOo 3.1.1    
100-10	100 10
101-10	101 10
102-10	102 10
103-10	103 10
                  OK

"LibreOffice Portable 3.3.0  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:6) tag libreoffice-3.3.0.4]"
100-10	100 10
100-9	101 10
100-8	102 10
100-7	103 10
                  NOT OK, see 3.4.5 

"LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) 
100-10	100 10
100-9	101 10
100-8	102 10
100-7	103 10
.
100-1	109 10
1000	110 10
1001	111 10

                  NOT OK, second substring used for creating series
                  100-0 modified to 1000

"LibreOffice 3.5.0"
100-10	100 10
100-9	101 10
100-8	102 10
100-7	103 10
                  NOT OK, see 3.4.5!

Also NOT OK with OOo 3.3, so problem seems inherited from OOo

@Kohei
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 3 QA Administrators 2015-02-19 15:38:11 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-03-07 13:45:16 UTC 
Reproduced.

Win 7 Pro 64-bit, LibO Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI
Comment 5 tommy27 2016-04-16 07:24:34 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2017-05-22 13:25:41 UTC Comment hidden (obsolete)
Comment 7 Xavier Van Wijmeersch 2018-10-13 16:34:45 UTC 
It seems to work with LibreOffice V6.0 ==> V6.2 master, here are the results

123456-0001
123456-0002
123456-0003
123456-0004
123456-0005
123456-0006
123456-0007
123456-0008


Version: 6.2.0.0.alpha0+
Build ID: fd41fb8392a4e9a27d9fd09071a5f1e2be4b5a0e
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: threaded

But its not working with LibreOffice V5.4.8 and lower
Can be closed
Comment 8 Buovjaga 2018-10-14 06:35:07 UTC 
Nice that we can close a 6 year old bug :)