— kindly asking for help for a cross check, it’s simple —
short:
-
pls. check the two attached pics, they show different and partly wrong values for the filtering of a table in calc, that blocks processing the filtering situation by a macro.
-
pls. check attached spreadsheet, ‘Zeige Filterfield’ shows the value .field for the first applied filter, see that while not! removing and re-applying autofilter the value for col. B and col. E are ‘1’, you may ignore ‘Filtrierung korrigieren’, it doesn’t work, the macro behind it gives some snippets of code to deal with the values …
long: while working on macros for fast easy filtering i have a strange effect:
the values for .field accessible by macros are partly wrong, depending on the row- and column offset of the database range against cell A1. one special case which blocks me from correcting the values in the macro is the following:
when filtering a database area whose header is partly left / below and partly right / above the ‘45 degree diagonal’ A1-B2-C3-D4-E5… and in which one column is filtered with ‘header’ on the left and one with header on the right of the diagonal, the following is stored in the saved file C:\fakepath\mikele_test_filterdescriptor_test13c.ods](/upfiles/15878181118669652.ods) for the definition of the filtration: see figure:
the two indented lines and there ‘field-number="-2"’ and 'field-number=“1” … if you do a more complex calculation you can work out ‘0’ and ‘3’ for the filter columns relative to the database area. This is what calc does, it shows the two columns B and E as filtered, and on the screen / with the mouse you can continue working with the values and filterings.
But! if you access the filtering by macro with the methods ‘getfilterdescriptor’ and ‘getfilterfields’ other values are taken for .field, and e.g. for the example table two! Filterfield entries with ‘1’ for .field are displayed, see attached screenshot:
I see - so far - no way to distinguish between them and decide for which the value of .field has to be corrected and how. In the example this is easy to spot for humans via the value in the cell, ‘name2’ is column B or ‘0’ and ‘vorname2’ is column E or 3 relative to the database area, but this is not suitable for automatic or for larger projects.
(imho because somewhere a bug a la confusion of line and column offset happened)
as soon as two different filter columns are converted to the same value for .field, a correction calculation ‘with onboard tools’ (macros) is no longer possible.
I haven’t found the filterfields under ‘thiscomponent’ or ‘oDoc’, although they should be there? but there are too many classes, superclasses, types, methods … I found them under ‘orange’ after ‘oDBRanges.getByIndex’, and there already ‘wrong’, before ‘getfilterdescriptor’ and ‘getfilterfields’,
I could use some help right now:
-
that other people check the behavior on other computers, not that i’ll file bugs for singular problems,
-
if someone knows where the filterfields are hidden in ‘ThisComponent’ that you could have a look there,
-
if somebody knows, or knows somebody who knows, how the values for saving in the file are calculated, and how they are calculated back when loading, then you could have a look at the code, without such a hint I’m stuck with the different levels of naming …
imho despite ‘exotic’ it’s worth some effort to pin this bug down, it might be the root for some other errors reg. filtering situations spread in bugs and ask …
‘getfilterdescriptor’ is hidden in ‘databaseranges’ under:
elementtype::methods::method(6)
in oDoc or ‘ThisComponent’ accordingly:
databaseranges::elementtype::methods::method(6)
thanks for all your help, I hope it can help to improve LO,
b.
(P.S. i also asked similar question in libreoffice-forum.de)
this question is related to:
https://bugs.documentfoundation.org/show_bug.cgi?id=129105
https://bugs.documentfoundation.org/show_bug.cgi?id=132120
https://www.libreoffice-forum.de/viewtopic.php?f=12&t=25362&p=76913#p76913
where i asked / posted during my ‘investigation’,
(edit: made images active)
