<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body><a class="email" href="mailto:newbie-02@gmx.de" title="b. <newbie-02@gmx.de>"> b.</a> changed <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - MACRO: SCRIPT: "getFilterDescriptor()" broken on fresh loaded files?" href="https://bugs.documentfoundation.org/show_bug.cgi?id=129105">bug 129105</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">See Also</td> <td> </td> <td>https://bugs.documentfoundation.org/show_bug.cgi?id=132488, https://bugs.documentfoundation.org/show_bug.cgi?id=132120 </td> </tr></table> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - MACRO: SCRIPT: "getFilterDescriptor()" broken on fresh loaded files?" href="https://bugs.documentfoundation.org/show_bug.cgi?id=129105#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - MACRO: SCRIPT: "getFilterDescriptor()" broken on fresh loaded files?" href="https://bugs.documentfoundation.org/show_bug.cgi?id=129105">bug 129105</a> from <a class="email" href="mailto:newbie-02@gmx.de" title="b. <newbie-02@gmx.de>"> b.</a> <pre>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: <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - filesave: fileopen: macro: xml: calc filtered ranges wrongly saved in .ods format? xml export / import buggy? affects filters in database ranges with offset to cell A1" href="show_bug.cgi?id=132488">https://bugs.documentfoundation.org/show_bug.cgi?id=132488</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>