Created attachment 126390 [details] Minimal test of non-appearing icons It seems like conditional formatting with an icon set fails to show any icons if all of the values in the range are strictly greater than the upper cutpoint threshold. (I discovered this originally in a spreadsheet of average GPAs where every category was above 3.0.) Consider the minimal attachment TestIconSet.ods. In column A are certain values with conditional formatting applied, in which icons appear correctly (this example was taken from the documentation at https://wiki.documentfoundation.org/Faq/Calc/141). In column B are values 3.1 or 3.3 with the same formatting applied, and no icons visible. In particular, the conditional formatting in each column was: All Cells, Icon Set, 3 Arrows, yellow >= 0, green >= 1. Some things we can try: - If any cell in column B is changed to the value 1 or below, then icons appear for all cells in column B. If that cell is then changed back to a value above 1 (by manual entry, not undo), then icons in column B all disappear again. - If the conditional formatting is edited so the upper green category is >= 3.1 or any higher value, then icons appear for all cells in column B. Again, if that criteria is edited to be anything below 3.1, then icons disappear from all of column B. - This malfunctions the same way for any icon set tested (it was originally discovered attempting to use Traffic Lights 1).
Reproducible Win10x64 Version: 4.0.6.2 (Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24) Version: 4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a Version: 4.2.8.2 Build ID: 48d50dbfc06349262c9d50868e5c1f630a573ebd Version: 5.1.5.1 (x64) Build ID: bb431b2be5fb7772067efc27a3cc98b6927c7b4c CPU Threads: 1; OS Version: Windows 6.19; UI Render: default; Version: 5.3.0.0.alpha0+ Build ID: 9dc3356f1499a2b90078be86ca7470eb2e96aba8 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-07-21_23:52:45
ok. The problem here is that one entry that is only used internally is a formula entry with 0%. As a result the minimum is the smallest value of the range (3.1) which is larger than the upper bound (1) and therefore we ignore the rule. I need to get back into the code to understand why I used this hidden entry for the zero entry.
Created attachment 126539 [details] A png that shows the issue. As far as I understand the bug, it is the same see the picture. Si je comprends bien c'est le même bug.
(In reply to Markus Mohrhard from comment #2) > ok. The problem here is that one entry that is only used internally is a > formula entry with 0%. As a result the minimum is the smallest value of the > range (3.1) which is larger than the upper bound (1) and therefore we ignore > the rule. > > I need to get back into the code to understand why I used this hidden entry > for the zero entry. Ah it is even easier. I have a safety check in there that is just wrong and causes the problem. Removing that check seems to solve the problem.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f3531bebd1746e2f3cec2a18d92322ab482ee2ab tdf#101104 this paranoid safety check actually causes a bug It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Review request for 5-2 and 5-1 in gerrit.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d9d85d6c989e848922841d6ce36ab3f4dad054dd&h=libreoffice-5-2 tdf#101104 this paranoid safety check actually causes a bug It will be available in 5.2.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Markus Mohrhard committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d66c353fb7ea7d47af2404e7e66cef0f6a690c3&h=libreoffice-5-1 tdf#101104 this paranoid safety check actually causes a bug It will be available in 5.1.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6cc9f2ee740f51bf49e031135ce7c44d19cefe9c tdf#101104: sc_subsequent_filters: Add unittest It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.