Apache OpenOffice (AOO) Bugzilla – Issue 92292
automatic filling of cells doesnt work as expected
Last modified: 2008-09-17 13:36:07 UTC
I entered into spreadsheet following entries under each other (dev300_m27): item 1.1 item 2.2 Selected both cells and dragged right corner down. Spreadsheet is filled like: item 1.1 item 1.2 item 1.3 item 1.4 As you see, Calc has its own opinion about my list and much worse, it replaces my second entry 2.2 with 1.2. (instead period here can be dash or something else).
When looking at this issue, may I draw your attention also at issue #70015, issue #74662 and issue #74733 that deal with improvements for AutoFill as well .
When filling strings only a simple "are there leading or trailing digits" detection and determining a step value is performed, no other numeric conversion is involved, especially no conversion of alleged floating point values and no pattern match. Replacing "item 2.2" with "item 1.2" may be considered wrong. But if left intact, what would you expect as a 3rd value? "item 3.3"?
Thats not important, maybe item 2.3 even if it is not expected, just I dont like that existing values are modified.
Hallo Eike! Overwriting of existing values during AutoFill is fine, as long as they are NOT part of the selection when starting AutoFill. But, selected cells must not be changed. You may wanna check the main competitor´s behaviour, that IMHO fits best to the user´s expectations in any constellation prior to AutoFill. (Damn, how do I hate stating this.)
I did some testing in OOo-dev m28 I entered in the first 2 cells a string and examined what happens when autofilling (using the drag method): Text entered in first 2 rows: A B C ------------------------------ 1 text 1.1 text 1.1 text 2 text 2.1 text 2.2 text ============================== after autofilling => 1 text 1.1 text 1.1 text 2 text 2.1 text !2.1 text! <== HAS CHANGED !!! 3 text 3.1 text 3.1 text 4 text 4.1 text 4.1 text Cell C2 should have never changed: at a minimum, it should not change, even IF the other cells are undefined. The optimal solution would be to detect the common string parts in the first 2 cells, remove them, and use the remaining numbers to increment. Alternatively, one could extract the whole number sequence. IF(cell_content == string) { ITERATOR = first_pos(cell_content) while(ITERATOR < end) { IF( *ITERATOR++ == number ) next IF( *ITERATOR++ == locale_dependent(".") ) { decimal_separator++ # we can also have dates or date-like strings IF( decimal_separator < 3) next ITERATOR-- # this is a decimal separator too much # will break after this } break } # we found our number-sequence } The alternative is to compare the 2 strings and extract ALL identical strings. Try to interpret as a number everything else that remains (that is different between the 2 strings).
Just to slightly update the described algorithm: - IF NO number sequence is found at the beginning of the string then the iterator should start backwards [left should have precedence over right] - this algorithm will fail with discontinues numbers, e.g. 1 text 1 2 text 2 The identical string algorithm would be slightly more stable, but would fail IF the true string part is different, e.g. 1 abc 1 2 axx 2 The behaviour would be undefined in this latter instance. Also, this latter algorithm would then have to increment every number sequence encountered (with possibly different steps). Though, this needs not be implemented immediately. Fixing the overwrite behaviour should however be fixed in a timely manner. Detecting a whole number sequence should probably follow closely.
Issue 5550 has a patch attached to change how increment is determined. Please evaluate. *** This issue has been marked as a duplicate of 5550 ***
Closing dupe.