[Libreoffice] [PATCH] fdo 42286 in calc solved ?

[Pierre-André Jacquod]

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...