https://bugs.documentfoundation.org/show_bug.cgi?id=145995
--- Comment #8 from Colin <that.man.co...@gmail.com> --- (In reply to Buovjaga from comment #7) > 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: > > + > + // 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); > + Not being a coder I only THINK my comment may be relevant; It appears to me that something may be performing detection in a column. if that detection is assuming it may encounter a condition lower down that same column then it could miss a situation where the upper table is more columns than the lower table AND the lower table is offset so it commences some columns to the right. Clearly, if the detection is over the entire columnar range of the upper table then I just ably demonstrated my stupidity. > I think first the undoing should be made to work. 100% Agree > 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. I cannot imagine any use for a procedure that ALWAYS actively destroys tables. Whoever invented backups is a saint;) -- You are receiving this mail because: You are the assignee for the bug.
