https://bugs.documentfoundation.org/show_bug.cgi?id=145995
Buovjaga <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Defined DATA ranges merge |Defined DATA ranges merge |destructively if cells |destructively if cells |separating them are |separating them are |inadvertently filled. |inadvertently filled | |(autofilter extending data | |area) Keywords|preBibisect |bibisectNotNeeded Version|3.5.0 release |3.4.0 release --- Comment #7 from Buovjaga <[email protected]> --- Knowing the issue appeared somewhere between 3.3 and 3.5, I did a rough search through the logs based on the release feature freeze dates: git log --all --grep="autofilter" -i --since="1.10.2010" --until="11.12.2011" sc Studying the log, this looked very relevant: commit 03417cf345a6044f97de4b1c18ba01807e39010f Author: Kohei Yoshida <[email protected]> Date: Fri Apr 1 21:05:08 2011 -0400 Re-implement DB area extension prior to autofilter launching. This time store the extended DB area permanently. This makes things a bit simpler. diff --git a/sc/source/core/data/documen3.cxx b/sc/source/core/data/documen3.cxx index c99145cd0309..afa80bc73d31 100644 --- a/sc/source/core/data/documen3.cxx +++ b/sc/source/core/data/documen3.cxx @@ -1354,6 +1354,15 @@ sal_Bool ScDocument::GetFilterEntries( SCCOL nEndCol; SCROW nEndRow; pDBData->GetArea( nAreaTab, nStartCol, nStartRow, nEndCol, nEndRow ); + + // Extend the DB area to include data rows immediately below. + // Note that the change is stored back to the DB. + SCCOL nCol1a = nStartCol, nCol2a = nEndCol; + SCROW nRow1a = nStartRow, nRow2a = nEndRow; + GetDataArea(nTab, nCol1a, nRow1a, nCol2a, nRow2a, false, false); + nEndRow = nRow2a; + pDBData->SetArea(nTab, nStartCol, nStartRow, nEndCol, nEndRow); + if (pDBData->HasHeader()) ++nStartRow; It has a follow-up commit commit 9f9ff37fe372897e2682a4bcedd2b76b9c770979 Author: Kohei Yoshida <[email protected]> Date: Fri Apr 1 23:04:45 2011 -0400 Extend data area for standard and special filters as well. The code now lives here: https://opengrok.libreoffice.org/xref/core/sc/source/core/tool/dbdata.cxx?r=7ad4641e#643 Commenting out the content of the ScDBData::ExtendDataArea function and compiling, it indeed stops adding data written to rows below the range to the autofilter. The function calls ScDocument::GetDataArea in https://opengrok.libreoffice.org/xref/core/sc/source/core/data/document.cxx?r=0fb98963#1069 which in turn calls ScTable::GetDataArea in https://opengrok.libreoffice.org/xref/core/sc/source/core/data/table1.cxx?r=97af15c8#880 Apparently it will modify the state of the area even though it confusingly has "Get" in its name, leading the reader to think it has a passive role. In a comment it says: "It may shrink or extend the area given as input". Call sites for ExtendDataArea: https://opengrok.libreoffice.org/xref/core/sc/source/core/data/documen3.cxx?r=97af15c8#1569 https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/tabvwshc.cxx?r=387a9c44#339 (multiple) I think first the undoing should be made to work. Then, the extending logic should be modified to stop extending, if it encounters an autofilter. Or can there be a use case where the current behaviour would be desirable? It seems counterintuitive and more like "the computer doing things I didn't ask it to", so I don't know who would miss it. -- You are receiving this mail because: You are the assignee for the bug.
