[Libreoffice-bugs] [Bug 133529] calc: ui: filesave: conflict between sort and filter, unclear use of tag 'table:orientation'

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #6 from b. <newbie-02 at gmx.de> ---
after some more investigation: 

0. the conflict between sort and filter reg. being 'master of the table
orientation' is older, oldest version i could get my hands on is 3.3.0.4,
already buggy, 

1. i could find the same conflict in apache openoffice 4.1.7, thus the 'root
cause' is inherited from OO, filter 'auto-harming' itself (wrong read in and
write out of filter definitions) is LO special and doesn't appear in AOO, 

2. up to version 3.5.1.2 the bug only affected sheets / ranges where you
defined a filter and a sort in different orientation, horizontal sort (left to
right) messes up the .field values for the filter, 

3. starting with ver. 3.5.2.2 something changed, at least the 'preset' for
bByRow in the database range (xmldrani.cxx), and the bug started messing up the
.field values on read of files which had been saved with active filtering,
without needing 'sort' to harm, 

4. a 'follow up bug' is that starting with a save after reload the filter
writes the tag/flag 'table:orientation="column"' to the range definition in
files, and accordingly wrong values for the fields to get them back to the
right buttons despite being calculated against the wrong start value, 

5. steps to test / verify: 

5a. spread integers 1 to 9 in B3:D5, e.g. B3:1, B4:8, B5:2, C3:5, C4:6, C5:7,
D3:4, D4:9, D5:3, 

5b. define a range for that area <data - define range> name it e.g. b, 

5c. apply auto-filtering to that range <data - filter - autofilter> (menu
varies slightly across versions), 

5d. set a filter on the first column (B), e.g. select '2' to be shown, 

5e. check the .field value for the filtering with the following macro: 

[code]
sub test
ntemp = thiscomponent.databaseranges(0).filterdescriptor.filterfields(0).field
end sub 'test
[/code]

put that in your macro file under tools - macros - edit macros - basic macros
or similar, place the cursor on ntemp and press F7 to get a 'watch' on the
variable, step through the macro with F8, see '0' to show up for the watch,
it's the correct value for 'first column of range, zero-based' 

5f. apply a horizontal sort to that range, <data - sort - options - left to
right - ok>

5g. recheck the filterfield with the macro, you'll get '1' as a wrong value,
would reference to col. C if used by macro / basic, 

6. conclude sort and filter are conflicting, 

7. only sort can set orientation=column, but filter can reset it, and both
evaluate the 'orientation', if they disagree (vertical filter / horizontal
sort) setting one of them will harm a previous set of the other, 

8. in whatever attempt to change anything, starting with ver. 3.5.2.2, filter
'auto-harms' it's definition by a mistake in the read in and subseq. mistake on
re-save of files - (in ods format!, as that's the (only?) format holding
orientation definitions), 

10. the initial conflict appears before write to file in runtime, 

11. it's two different - but closely related - problems, 
11a. sort-filter conflict reg. orientation, and 
11b. filters problem how to read in and write range definitions, 

12. each of them can be solved by either: 
12a. different 'orientation-definition' for sort and filter, in memory and in
files, or 
12b. 'filter' ignoring the orientation definition handeled by 'sort', in memory
and in files, (in detail: perform it's own and independent calculation of
.field values against he correct - column - offset / startCol.),

-- 
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/20200606/b8115489/attachment-0001.htm>