[Libreoffice-bugs] [Bug 129105] MACRO: SCRIPT: "getFilterDescriptor()" broken on fresh loaded files?

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=129105

b. <newbie-02 at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=13
                   |                            |2488,
                   |                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=13
                   |                            |2120

--- Comment #3 from b. <newbie-02 at gmx.de> ---
hello @Buovjaga, 

thanks for taking care, and sorry for having been imprecise ... 

it's been some time since i wrote this, may be - i hope so - this: 

https://bugs.documentfoundation.org/show_bug.cgi?id=132488

is the source of evil, i'd put it in another bug because it's not
'getfilterdescriptor' being wrong but the .field-values saved in the xml file. 

for the case it's not, or just 'for the records' a step-by-step workthrough for
this sample: 

> I opened the file, went to Tools - Macros - Run Macro.

ok, to see the problem evolving take 'edit macro' instead, 

> I chose PreviousFilterShortcut from the file.

correct

> Result is that all of the data was hidden.

that's not the intended result of the macro, it should step-back the filter to
the 'next-less' value in that column, if none is found  to the largest, but
it's intended from the sample / bug report to show the fault, 

> Is this good or bad? I have no idea after reading your description and comments.

'bad', let me explain the details: 

on load of the file 'as downloaded', sheet2 is displayed with the cursor in E2
(hidden), if you have another display change to sheet2, if the cursor is off
from  E1:E15 place it on E3, 

in the macro editor set 'afields' as watch variable (bottom left), 

step through the macro with F8, 

in line 49: 'aFields()=oFilterDesc.getFilterFields' 
afield get's assigned the actual filtering condition, check afields(0).field
(unfold afields by clicking the v-hook, within that unfold afields(0) by
clicking the v-hook), see Field = '4'. 

Field should be the value 'filtered column relative to database area
zero-based', in this sample column C should be 0, D be 1, and E - the filtered
one - should be 2, not 4! from this point on titanic will sink. 

in line 54: 'if aFields(n).Field=Column -
oRange.ReferredCells.RangeAddress.StartColumn then' 

a decision is made if the filtered field is valid for the actual column (the
loop is a sort out which field is valid), the check is made against the correct
calculated value for .field for column E (4-th column zero based) minus start
column of the database area (2-nd col (C, zero-based)) that fails as 2
(calculated) is compared to 4 (fetched from the file), thus the 'unfiltering'
of the actual column doesn't work, 

after that and based on the fault instead of changing the actual filter for col
E to 'not ""' that condition is applied to col '2', the area is re-filtered,
based on that filtering the 'previous value' is evaluated (to '3'), and put in
the filtering condition afields(1), and then instead of assigning one changed
filter to the area two conditions are applied, one for .field being 2 requiring
'3' in the column and one for .field being 4 requiring '3' in the column, not
met in any row, thus 'all off', 

you can see that both columns 'absolute 2 - relative 0 - C' and 'absolute 4
relative 2 - E' have filtering conditions applied at the end of the macro ,
check the dropdown fields in the header row, both blue, both 'dotted', and both
showing irrational conditions on click, 

that's how it's 'going wrong', 

do the same on sheet1, everything fine as no start-column-value has to be
respected, absolute and relative column numbers are identical, filter condition
for col. E is changed to '6', 

do the same on sheet3, it tries to filter columns '2' and '6', only one of them
is visible in the header, 

do the same on sheet4, it tries to filter columns '2' and '4', the value
fetched from the file is 4 for col. 6, imho caused by the 'row-offset' of the
database area, 

do the same on sheet5, everything looks correct, col E is re-filtered to 6,
imho the result of two errors - wrong evaluation of col-offset and wrong
evaluation of row offset - canceling each other out ... 

> Note: please try to separate the reproduction steps from any analytical writing.

i'll try, it is not easy (for me) to present difficult mistakes and complex
correlations that I have not yet understood myself, i sometimes see 'there is
something wrong' without being able to explain the reason. 

since most of the 'simple' errors in calc are solved in the meantime it will
happen more and more often that you have to describe strange things with long
explanations, i know that this is unpleasant for the developers ... i try my
best to help instead of annoying. 

If you want to help me, give me an example how i should have presented this
tricky bug better, 

and keep your fingers crossed that the analysis in #132488 is correct, and
someone will soon be found who can correct it, 

if you can spend time pls. chek it and - if bug - set to 'new', 

Without anticipation, it could face a difficult situation of how to deal with
all the 'old' files stored with wrong values at users ... may be they'll have
new problems after a fix ... 

reg. 

b.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200501/6593df38/attachment.htm>