to repeat, do the following: 1. enter text "January" in a cell (without the quotes) 2. select a range of cells, including the first text 3. go to Edit > Fill > Series of main menu 4. select the type of series AutoFill 5. Press OK instead of the list in January February March April and so on we will see only January a blank cell in through In the Quick Start Guide is written that: "AutoFill – forms a series directly in the sheet. The AutoFill function takes account of customized lists. For example, by entering January in the first cell, the series is completed using the list defined in LibreOffice > Tools > Options > LibreOffice Calc > Sort Lists." - but it does not work!
Confirming. AutoFill in general does not work correctly.
I confirm this bug. The function ‘Fill Series – AutoFill’ does not know how to use The Sort List (Tools – Options – LibO_Calc). This is a regression to LibreOffice 4.1.5, so the error status is critical. -- OS: Windows XP (32 and 64 bit); LibODev 4.2.3.0.0+ (Build ID: 4274001144adeb0b0a1e7da05d52c1bedbe899e5, TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-02-27_08:31:36) OS: Lubuntu 13.10 (64 bit); LibreOffice 4.2.2.1 (Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f) -- 1. Create a new spreadsheet. 2. Select multiple cells in any column. 3. Select the menu ‘Edit – Fill – Series..’ 4. Select the option ‘AutoFill’ in The Series type. 5. Write 'Sun' (for example) in The Start value and click 'OK' button. 6. Cells are not filled with names of days of the week, one after another.
I confirm the bug too. It applies not only predefined lists but any series: 1. Fill first three cells in a column with 1, 3, 5. 2. Select the range in the column including first three cells. 3. Apply Autofill to selected range. You expect to see a sequence of odd numbers but you get something else.
I confirm this bug for LibreOfficeDev 4.3.0.0.alpha0+: Build ID: 4402efc18ae16e279d55858946d2c8b8972f3f9f TinderBox: Win-x86@39 Branch:master Time: 2014-03-04_00:54:43 OS: Windows XP sp2 64-bit Edition
Created attachment 95166 [details] gif animation Preview the animation please! -- This function (AutoFill) works fine on the row, but it does not work, if you select a column. It is possible that the adding empty cell makes the block of the AutoFill’s work.
Thank you Ape for having noticed this very interesting point! I started from your example to know where the bug could be. I noticed this: http://opengrok.libreoffice.org/xref/core/sc/source/ui/docshell/docfunc.cxx#4430 nCount in OK/horizontal case gives 6 nCount in KO/vertical case gives 5 nCount seems to correspond to the number of cells to fill (after the one already filled by first value) On gdb session, if line 4455 of this same file, I force the nCount value to 6. vertical case gets OK.
Keeping on with debugging (trying to fill A1/A7), I got this bt : #0 ScColumn::GetEmptyLinesInBlock (this=0x2aaacdf7b010, nStartRow=0, nEndRow=6, eDir=DIR_BOTTOM) at /home/julien/compile-libreoffice/libo/sc/source/core/data/column2.cxx:1238 #1 0x00002aaac8fd1ccb in ScTable::GetEmptyLinesInBlock (this=0x2aaacdf7b010, nStartCol=0, nStartRow=0, nEndCol=0, nEndRow=6, eDir=DIR_BOTTOM) at /home/julien/compile-libreoffice/libo/sc/source/core/data/table1.cxx:1012 #2 0x00002aaac8e2d346 in ScDocument::GetEmptyLinesInBlock (this=0x1602238, nStartCol=0, nStartRow=0, nStartTab=0, nEndCol=0, nEndRow=6, nEndTab=0, eDir=DIR_BOTTOM) at /home/julien/compile-libreoffice/libo/sc/source/core/data/document.cxx:5681 #3 0x00002aaac94a3a9f in ScDocFunc::FillSeries (this=0x1605840, rRange=..., pTabMark=0x16f0810, eDir=FILL_TO_BOTTOM, eCmd=FILL_AUTO, eDateCmd=FILL_DAY, fStart=1.6999999999999999e+307, fStep=1, fMax=1.6999999999999999e+307, bRecord=true, bApi=false) at /home/julien/compile-libreoffice/libo/sc/source/ui/docshell/docfunc.cxx:4450 and ScTable::GetEmptyLinesInBlock returns 5 (instead of expected value 6). Then I unwinded from there. 1235 case DIR_BOTTOM: 1236 { 1237 // Determine the length empty tail segment. 1238 size_t nLength = nEndRow - nStartRow + 1; 1239 std::pair<sc::CellStoreType::const_iterator,size_t> aPos = maCells.position(nEndRow); 1240 sc::CellStoreType::const_iterator it = aPos.first; 1241 if (it->type != sc::element_type_empty) 1242 // end row is already not empty. 1243 return 0; 1244 1245 // length of this empty block from the tip to the end row position. 1246 size_t nThisLen = aPos.second; 1247 return std::min(nThisLen, nLength); 1248 } nLength = 6 but nThisLen = 5 which brought me there: workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector_def.inl 1231 template<typename _CellBlockFunc> 1232 typename multi_type_vector<_CellBlockFunc>::const_position_type 1233 multi_type_vector<_CellBlockFunc>::position(size_type pos) const 1234 { 1235 size_type start_row = 0; 1236 size_type block_index = 0; 1237 if (!get_block_position(pos, start_row, block_index)) 1238 throw std::out_of_range("Block position not found!"); 1239 1240 typename blocks_type::const_iterator block_pos = m_blocks.begin(); 1241 std::advance(block_pos, block_index); 1242 const_iterator it = const_iterator(block_pos, m_blocks.end(), start_row, block_index); 1243 return const_position_type(it, pos - start_row); 1244 } start_row = 1 (instead of 0). which finally brought me here: 551 template<typename _CellBlockFunc> 552 bool multi_type_vector<_CellBlockFunc>::get_block_position( 553 size_type row, size_type& start_row, size_type& block_index) const 554 { 555 for (size_type i = block_index, n = m_blocks.size(); i < n; ++i) 556 { 557 const block& blk = *m_blocks[i]; 558 if (row < start_row + blk.m_size) 559 { 560 // Row is in this block. 561 block_index = i; 562 return true; 563 } 564 565 // Specified row is not in this block. 566 start_row += blk.m_size; 567 } 568 569 return false; 570 } We don't go line 562 at the first time so start_row is incremented. Now I'm quite stuck because I don't know how blocks work. Kohei/Eike/Markus: any idea?
I'll take this.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9d54a7f67196cac2a5701c06d8dc55f102d0af60 fdo#75718: Write unit test for this. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=01de94471c20a8b9c36d6080638d70e57eac55bf fdo#75718: Correctly count the length of trailing empty range. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
4.2 backport: https://gerrit.libreoffice.org/8501
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=92a2cb1bc23d9b0e099f34bcd4c2b89d3682ce60&h=libreoffice-4-2 fdo#75718: Correctly count the length of trailing empty range. It will be available in LibreOffice 4.2.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Fixed.
Checked on master sources updated today, thank you Kohei!