Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hello,

Thanks for your hints. It took some times, but know I have clearly identified the problem , but I do not if my solution is right or could create more problems.

In short, the problem is that GetAreadData is called each time the filter determines its values, instead of using the current area. This does not have influence, as long as your selection area does not end with empties rows or empties columns.

But this behaviour produce a wrong result as soon as your filtered area ends with empties rows, and as special case, if you select all rows, since it decreases the area of 1 row if the last row is empty.

Basically this happens with the call of function ExtendDataArea. This originates from documen3.cxx, function GetFilterEntries line 1390 (the call itself is at line 1398). (more details below, if needed)

My solution: suppress this call...
I have tested it and it seems to work. I did not managed to find a case where something is broken with the filter..

But it seems me too simple.
Could you check this before I push it ?

If Ok, would you like then to approve it & cherry-pick it to 3.4.5 ?

Thanks & best regards
Pierre-André

ps: if what I did is right, I will then update the bug ticket

-------------------

What happens?
As I understand after debugging and following the logic, each time the filter is activated (it is an auto-filter) it tries do determine the data range when it search for its value to show in the filter drop-down.

For that it searches the biggest contiguous area of data, as when applying the filter without selection.

Except the fact that here it goes wrong, since an area has already selected (either manually or stored as <table:database-range ... tag. which contains and finish (important in this analysis) with several empty rows (columns would produce the same problem). And it tries to fit the Area with the GetAreaData algorithm, starting with a predefined area. The result: it does not extend it (next row is emtpy), but thinking he as extended the area of one row to far (this the last row int the area is empty), it reduce the selected area of one row.

And this produce the strange comportment described. (more detailed analysis below).

Each time the filter value is changed , the function ScTAble::GetAreaData (in sc/source/core/data/table1.cxx, line 740 in my check-out) is called. At the end of the called function, there is a check: if the last row is empty, then the Area is reduced by one, deacreasing its last row value by 1 (line 835/836)
if (!bFound)
    --rEndRow;

This is obviously wrong, especially if you select e.g the 3 first columns (completely) and then apply auto-filter. Since empty lines *are* part of the selection... and not only the last one is empty. So each time I change the filter value, I reduce by 1 the last row number...

I see that the content.xml ends with some strange empty row
It is ill-formatted by the user ;-)  Cells in columns A:G down to the
....
However, strange are the spurious entries with
table:visibility="filter"

no, this is the result of this filter changes coupled with the order of "ALL" value filter or partial filters.

This also creates a mess with the storage of
<table:database-range table:name="__Anonymous_Sheet_DB__0" ....
reducing the area within the range, depending when you save your file...



From 568c0635089964488a05043d7422eb40be15ccaf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Andr=C3=A9=20Jacquod?= <pjacquod@alumni.ethz.ch>
Date: Tue, 15 Nov 2011 20:55:53 +0100
Subject: [PATCH] fdo#42286 do not change selection area when determining filter values

Just use the current area, does not redetermine it in order to
find the list of values for drop-down of the filter.
---
 sc/source/core/data/documen3.cxx |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/sc/source/core/data/documen3.cxx b/sc/source/core/data/documen3.cxx
index 273af5f..14b0655 100644
--- a/sc/source/core/data/documen3.cxx
+++ b/sc/source/core/data/documen3.cxx
@@ -1395,7 +1395,6 @@ bool ScDocument::GetFilterEntries(
         ScDBData* pDBData = pDBCollection->GetDBAtCursor(nCol, nRow, nTab, false);  //!??
         if (pDBData)
         {
-            pDBData->ExtendDataArea(this);
             SCTAB nAreaTab;
             SCCOL nStartCol;
             SCROW nStartRow;
-- 
1.7.3.4


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.