Enter in any cell: =sum(5,11,26,38,17,55) Calc will translate that formula into: =SUM(5,110,260,38,17,55) Extra zeroes cannot be deleted.
Shouldn't it be =SUM(5;11;26;38;17;55)
@Urmas, I entered the formula exactly as shown here, and it was not corrupted. Please attach a spreadsheet with 0's added that cannot be deleted. @Tomaz Vajngerl, Calc of the version in this bug on my system (Ubuntu 12.04) accepts commas.
Created attachment 89408 [details] The formula
Additionally, after loading a saved document, there are periods (.) appearing in the formula.
I'm reproducing the result =SUM(5,110,260,38,17,55) in formula bar and ERR509 in the cell when using the wrong parameter separator according to my locale. (comma instead of semi-colon) If I use the correct separator (semi-colon for French_FR) formula and his result is correct.
I have the same results as Gerard. Changing the separator in Menu/Tools/Options/LibreOffice calc/Formula - Separator - Functions, to comma then there is no issue with the formula. For me there is not a bug.
If the formula is incorrect, it should be reported as such, and not be transformed arbitrarily. That is definitely a bug.
Created attachment 94994 [details] Screenshot with the error in the status bar. In the status bar is showed an error: 'Error: Invalid name' I think for calc it is a text without quotes and try to find a range name, what of course it doesn't find.
But you are right, adding zeroes is a bug and the change with save and reopen.
*** Bug 86999 has been marked as a duplicate of this bug. ***
** 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
Reproducible in 5.2.1 and current master (Kubuntu 16.04). Also checked in old versions: 3.5.4 and 3.6.5 not reproducible, 4.0.6 reproducible -> regression between 3.6 and 4.0.
Hi @Stanislav, what is you default separator?
I tested this with the same setup as bug reporters had: semicolon as the separator and incorrectly used commas in formula. (There was a change from comma to semicolon in the default separator between 3.6 and 4.0, so it might be related to the regression.)
** 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with the same result in 5.4.1 and in: Version: 6.0.0.0.alpha0+ Build ID: 141fe1c5e7fbf67a083b34e49e19b6ea78a0eb2b
Still reproducible with the same result Version: 6.1.0.0.alpha1+ Build ID: 212807f77b78c69263f8aae51dcdc73e8017c53a CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
(In reply to Stanislav Horacek from comment #14) > I tested this with the same setup as bug reporters had: semicolon as the > separator and incorrectly used commas in formula. (There was a change from > comma to semicolon in the default separator between 3.6 and 4.0, so it might > be related to the regression.) I was going to bibisect this, but I do not reproduce the appearing of zeroes, when I do it from scratch. Also, I can delete the extra zero from the example file in any version.
For me it is still reproducible with the addition of extra zeros in: Version: 6.3.0.0.alpha0+ Build ID: ac7508c31873d79e56b406c9bf931caae63d4975 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-12-14_16:04:08 Locale: cs-CZ (cs_CZ.UTF-8); UI-Language: en-US Calc: threaded
formula with semi-colon i have 152 as result, but with comma error code 509 and extra zeroes Version: 6.3.0.0.alpha0+ Build ID: aeb54120a47768ca3dc92f5bbb715ee491646e48 CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk2; Locale: nl-BE (en_US.UTF-8); UI-Language: en-US Calc: threaded
with AOO 4.1.5 (de-DE) and LO 3.6.7.2 (Build ID: e183d5b): =SUMME(5,11,26,38,17,55) results in: =SUMME(5,110,260,38,17,55) so i think this issue is not a regression
*** Bug 129998 has been marked as a duplicate of this bug. ***
Dear Urmas, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Just like in 2018, I don't reproduce it. I just get Err:508 and no extra zeroes appear. Arch Linux 64-bit Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 71be70b16b37fb3c1b6331ab3581300556ecc7aa CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 7 January 2022
I tested it for two UI languages with the following results: Err:508, no zeros added for: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 102a29d59a0a195ee42a52d5563adf99fa32a541 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: fi-FI (cs_CZ.UTF-8); UI: en-US Calc: threaded Chyba:509 (i.e. Err:509), zero added to "11" for: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 102a29d59a0a195ee42a52d5563adf99fa32a541 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: fi-FI (cs_CZ.UTF-8); UI: cs-CZ Calc: threaded
That's really strange as in 2018 you could repro with Locale: cs-CZ (cs_CZ.UTF-8); UI-Language: en-US and now you can't repro with Locale: fi-FI (cs_CZ.UTF-8); UI: en-US while you can repro with Locale: fi-FI (cs_CZ.UTF-8); UI: cs-CZ Weird mix of language & locale interaction.
I confirm the problem with Czech UI: Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: cs-CZ Calc: threaded
Confirming, now I cannot reproduce it with: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 102a29d59a0a195ee42a52d5563adf99fa32a541 CPU threads: 4; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded There was indeed a change after 2018 (providing that I didn't mess up information in my comment from that time:))
@Eike, I thought you might be interested in this issue
Fwiw, for me the same happens in cs-CZ locale with en-US UI and in fi-FI locale with en-US UI and in cs-CZ locale with cs-CZ UI and in de-DE locale with de-DE UI and in de-DE locale with en-US UI. A difference to 2018 or 2013 might be that IIRC back in time you could force the function parameter to ',' comma even if the decimal separator was ',' comma as well, which makes no sense and is not possible anymore. fi-FI and cs-CZ and de-DE locales have ',' comma decimal separator => function parameter separator is ';' semicolon. Smallest reproducer: =5,11,2 What happens is that 5,11 is parsed as numeric value 5.11 stopping at the second ',' comma and the following ,2 is parsed as numeric value 0.2 with a missing operator in between resulting in error (Err:509, operator missing), the so far parsed and tokenized formula is displayed and concatenating values 5.11 and 0.2 as string with a decimal ',' comma separator results in 5,110,2 Not much we can do about, unless we ditch the requirement that ,2 can be parsed as 0.2 (i.e. a leading 0 would have to be present). Or throw yet more logic at it to remember the original input for each token.