1) Type TRUE in cell A1 2) Autofill/drag A1 to A10, all cells show TRUE 3) Type FALSE in A11 4) Enter in B1: =COUNTIF(A1:A11,TRUE) , hit enter The formula changes to =COUNTIF(A1:A11,1) and displays result of 1 not 10. If you reformat cells A1 to A11 as number (1234 not gerneral) they show 1,2,3,4..10,0. Per definition FALSE is 0, TRUE is any number not equal 0. The correct change of the COUNTIF function has to be =COUNTIF(A1:A11,"<>0") or leave TRUE in place.
See also discussion in http://ask.libreoffice.org/en/question/16615/how-to-count-true-entries-in-a-column/
Confirmed under Ubuntu 10.04 x86_64 running v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a. Status set to NEW. Severity set to Normal as there are viable workarounds. To be clear, as per the AskLO discussion linked in comment #1, it is only Fill Series (click-n-drag unmodified / CTRL+3 with increment of 1) rather than Fill Down (click-n-drag with CTRL modifier / CTRL+D) that causes the problem.
The string TRUE is turned into 1 while typing, dragging down increments this number. (Holding the Ctrl key while typing is a workarround). Booleans in OOo and LibO are not true booleans but numbers with specific format. Typing =TRUE() and dragging produces the expected result (TRUE in all rows as you drag a formula , not a number). Writing a string and rely on number recognition is not the best way to have the boolean value. Don't forget that number recognition is locale dependant (TRUE in EN, VRAI in FR...etc). So the best way is to use TRUE() and FALSE() formula.
(In reply to comment #3) > Writing a string and rely on number recognition is not the best way to have > the boolean value. Don't forget that number recognition is locale dependant > (TRUE in EN, VRAI in FR...etc). So the best way is to use TRUE() and FALSE() > formula. Thanks for the clarification. Given this information, I agree. This report would therefore seem more an enhancement request (if anything) than bug. Added missing "T" to "COUNTIF" in summary.
(In reply to comment #4) > (In reply to comment #3) > > Writing a string and rely on number recognition is not the best way to have > > the boolean value. Don't forget that number recognition is locale dependant > > (TRUE in EN, VRAI in FR...etc). So the best way is to use TRUE() and FALSE() > > formula. > > Thanks for the clarification. Given this information, I agree. This report > would therefore seem more an enhancement request (if anything) than bug. > Added missing "T" to "COUNTIF" in summary. Should this report be set as enhancement request? Or perhaps even closed? For now, I'm lowering priority and setting as enhancement request, since alternative or more adequate procedures already exists (using "=true()" among others). If there are reasons to change the status, feel free to change it accordingly. Regards, Ady.
(In reply to comment #5) > Should this report be set as enhancement request? Or perhaps even closed? I think it could be closed as WONTFIX, but it would be good to hear from the original reporter.
This bug is in my opinion NOT an enhancement. It is a real bug. The Autofill just enters numbers incrementally in cells which is correct per OASIS definition (and all programming languages I know). The error is inside of the COUNTIF function. I gave the solution in my original report. >The correct change of the COUNTIF function has to be =COUNTIF(A1:A11,"<>0") or >leave TRUE in place. I can not estimate how much work the change from "1" to "<>0" in the COUNTIF function is. If it is too much work then let it be a WON'T FIX. I changed it back to NORMAL from ENHANCEMENT.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Countif gives #NAME? result for me. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 437210d58f32177ef1829d704f7f4d2f1bbfbfdd TinderBox: Win-x86@39, Branch:master, Time: 2015-06-18_07:21:56 Locale: fi-FI (fi_FI)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d7984d88e6e611e84fef41e7bb092c127b5db26b Resolves: tdf#64001 exclude "boolean" value cells from increment during Fill 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.
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=90f6876bec3989e3fc8e4f961604c8d00e735eb9 uitest for bug tdf#64001 It will be available in 6.1.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.
The test exist, set status to Verified.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3eac1691aae5d788269c538fbf609e625fac0c84 tdf#64001: sc: move UItest to CppUnittest 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.