Steps: 1. New calc, select column A; 2. Edit - Fill - Series: start value = 1; end value = 10; increment = 1. OK. Current behaviour: Calc fills to row #1648576, with "#NUM!" in cells below row #10. Expected: Only A1-A10 is filled. Calc should detect that the "end value = 10" so that the last cell to be filled is A10.
Makes sense to me. Marking as NEW. Kind regards, Joren
Migrating Whiteboard tags to Keywords: (needsDevEval)
I think this is a bug (still present in LO 5.2.3.3), not an enhancement request. The bug always occurs when the series with an end value is shorter than the selected range. It works in OpenOffice.
Actually this is a regression. Move from ENHANCEMENT to NORMAL. It works OK in libreoffice-3.3.0. I will try to bibisect.
Bibisected result using the releases repo: f829590e1c73663ee9463c2f54219794b88764b0 is the first bad commit commit f829590e1c73663ee9463c2f54219794b88764b0 Author: Matthew Francis <mjay.francis@gmail.com> Date: Tue Apr 14 22:38:54 2015 +0800 libreoffice-3.6.0.4 LibO_3.6.0.4_Linux_x86-64_install-deb_en-US.tar.gz :040000 040000 5cc32187bef50534e7ca1cd5fd011d61d36ef905 162535d6baaa7317ad36bcfd7ec854040612a7d7 M opt git bisect log: # bad: [4f2186cd72652db35eebe5b1b9d3693723433b85] libreoffice-4.0.0.0.beta1 # good: [52afdea50650697a791234f22d2cf2147498b06e] libreoffice-3.3.0 git bisect start '4f2186cd72652db35eebe5b1b9d3693723433b85' 'libreoffice-3.3.0' # good: [4a9bc438d62f90e8bf687683d854c3a044397505] libreoffice-3.5.3rc2 git bisect good 4a9bc438d62f90e8bf687683d854c3a044397505 # bad: [ac15b75361b54e9d29f2ed9e3203b731fd0a0d29] libreoffice-3.6.2.2 git bisect bad ac15b75361b54e9d29f2ed9e3203b731fd0a0d29 # good: [17cbb2ce32a1c75418e0cc10a2a146576a1eb7ee] libreoffice-3.5.6rc2 git bisect good 17cbb2ce32a1c75418e0cc10a2a146576a1eb7ee # bad: [f829590e1c73663ee9463c2f54219794b88764b0] libreoffice-3.6.0.4 git bisect bad f829590e1c73663ee9463c2f54219794b88764b0 # good: [3b5b2e1244308952f7b6d19114e0f7200b0b8f0c] libreoffice-3.5.7rc2 git bisect good 3b5b2e1244308952f7b6d19114e0f7200b0b8f0c # first bad commit: [f829590e1c73663ee9463c2f54219794b88764b0] libreoffice-3.6.0
I am adding bug 48449 as see also because the commits which fixed that bug are the only commits that is between version 3.6.0.0 and 3.6.0.4 which are related to fill series.
I think the fault is the code else if (bOverflow) aCol[nCol].SetError(static_cast<SCROW>(nRow), formula::errIllegalFPOperation); in the function ScTable::FillSeries in the file sc\source\core\data\table4.cxx https://cgit.freedesktop.org/libreoffice/core/tree/sc/source/core/data/table4.cxx#n1750
bisect is used when the commit introducing the regression has been identified, which is not the case here...
Bibisected on Linux with 43all repo, pointed to range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=250feedd8e50e5eb52682a194823567ba5287c60...ee7084c4f720c932df67c8ff033dab4d8d556179 There is a commit about FillSeries https://cgit.freedesktop.org/libreoffice/core/commit/?id=f61cbce529d039bb0e208e81cf66974cc4428420 commit f61cbce529d039bb0e208e81cf66974cc4428420 (patch) tree 5bf31db12d5ff5ac4a799778bde4f4017bfbd5fb parent a78a7ee9f7b1db56a6fa7e082f410db5a8db2f18 (diff) make ScTable::FillSeries work correctly with hidden rows/columns Adding Cc: to Markus Mohrhard
Still reproducible on master Version: 6.3.0.0.alpha1+ Build ID：d2fa9c0d657877c967e41fdd0091f81d1b7ca048 CPU 线程：4; 操作系统：Linux 4.18; UI 渲染：默认; VCL: gtk3; Locale: zh-CN (zh_CN.UTF-8); UI-Language: zh-CN Calc: threaded
*** This bug has been marked as a duplicate of bug 126577 ***