Description: using Libre Office portable 6.2.2.2 Steps to Reproduce: 1. create table 2. select cell (a) set variable with value 1000, number formating with thousand separator i.e. #.##0 3. select another cell (b) and insert value of variable using "show variable", number formating with thousand separator i.e. #.##0 4. select a third cell (c), press F2 and enter cell b x 10 5. press F9 to calculate values Actual Results: cell c gives 0 as result Expected Results: cell c should give 1000 x 10 = 10.000 as result Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: change the numberformat of the variable in cell b to no thousand separator, press F9 -> cell c shows the correct value of 10.000 this is reproducible with other formating that contains non digits (like adding m² #.##0" m²") reproducable on two machines this issue was observed after changing from LibreOffice portable 6.1.2 to 6.2.2 it can not be reproduced on 6.1.2
Created attachment 151216 [details] writer doc with table and variable showing issue
reproducible with: Version: 6.2.3.2 (x64) Build-ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: steps to reproduce: - open attached document - double click variable in cell A2 - change cell format to -1.235 - press F9 - value in cell B2 changes to 0 *not* reproducible with: Version: 6.1.6.3 (x64) Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc:
seems to have started with: https://gerrit.libreoffice.org/plugins/gitiles/core/+/9336286a7ea5385541344f444e6f8702c85bdacb commit 9336286a7ea5385541344f444e6f8702c85bdacb [log] author Eike Rathke Fri Nov 30 14:20:49 2018 +0100 committer Eike Rathke <erack@redhat.com> Fri Nov 30 22:15:22 2018 +0100 tree ed4d9276ca37b497e02fabd9fbd0b9d2f139f1d2 parent 4632afbd9ecdf85f3980b41fa9d58b6099aa2d81 [diff] [API CHANGE] Resolves: tdf#42518 new KParseTokens::GROUP_SEPARATOR_IN_NUMBER Default unset bit now does not accept/skip group separators in numbers. See .idl description comment for why this is incompatible and how. This actually uncovered a "bug" (or at least unexpected) in the Math parser that parsed "0," as one entity instead of "0" followed by ",". As obtaining the text form appends a blank after each entity the sw/qa/extras/rtfexport/rtfexport.cxx testMathEqarray() testcase had to be adapted. /cygdrive/d/sources/bibisect/bibisect-win32-6.2 $ git bisect log # bad: [d60ae8383378fcecc7ab077670bf45208a214c71] source e45c30858dec1dd705b9144fab981a3c8819ba96 # good: [b0a56ec98b1368cb5e3e531e0b3f69565af91609] source 3a801799536e6870f2fb111b1cc00b9575a35a39 git bisect start 'master' 'oldest' # good: [5180a3b7a5dc530ad7ec5bd6e5cefecf85beab7e] source 8bcc4a98d78869d6839821b9747602777f00ebaf git bisect good 5180a3b7a5dc530ad7ec5bd6e5cefecf85beab7e # good: [1473ee9b216ec27c5410a08036aef0a4b857841c] source 93c817971d76ff5020d4210229896a35d357a371 git bisect good 1473ee9b216ec27c5410a08036aef0a4b857841c # good: [9fbd095c4236de2f48da51d83c976a942dfa6a31] source 8ff55c16e853600fdac6164d34ff35421a1f112e git bisect good 9fbd095c4236de2f48da51d83c976a942dfa6a31 # good: [27454ec8bb96a7fc768bddfcf7e19099936d098a] source 9553f2afd0527ba435dae7bf4506c620a943b150 git bisect good 27454ec8bb96a7fc768bddfcf7e19099936d098a # good: [94eecb1ddc570e0f8c253b2d48d415cca763d228] source 1d988778095ecbe84f1a1002511377d0708b3443 git bisect good 94eecb1ddc570e0f8c253b2d48d415cca763d228 # good: [69d20cfa5cb1238bb15feb4149c0e362b808f008] source 4b7cbb569e52e483a5edda8afe27d423e428edbb git bisect good 69d20cfa5cb1238bb15feb4149c0e362b808f008 # good: [3468d19ea957918870481bfc9f82a9b80c76ca69] source 6e8605ee6de4ead23925476f0e945b51dea26be0 git bisect good 3468d19ea957918870481bfc9f82a9b80c76ca69 # good: [db592044a1d82ff045cf753f5f05000b3d3533ab] source 9766892044fc69de18d0395ec2c4a0e652165c23 git bisect good db592044a1d82ff045cf753f5f05000b3d3533ab # bad: [fa3f1cbd5e495466aad8b5bce09143691ea08b69] source 4490d4edcff54e439ee3e97b5ce88dc3f065881b git bisect bad fa3f1cbd5e495466aad8b5bce09143691ea08b69 # good: [a46cc254e889043f93c8029a092e039b77bc1148] source f8c76ab81bb5b443c5077c2cac9112f8e0ee6855 git bisect good a46cc254e889043f93c8029a092e039b77bc1148 # bad: [c17fbd5031acd0c942669d81213488001c908769] source 9336286a7ea5385541344f444e6f8702c85bdacb git bisect bad c17fbd5031acd0c942669d81213488001c908769 # good: [8f6028efc3319237e74bdc7b79ba2ae588c69d70] source 4632afbd9ecdf85f3980b41fa9d58b6099aa2d81 git bisect good 8f6028efc3319237e74bdc7b79ba2ae588c69d70 # first bad commit: [c17fbd5031acd0c942669d81213488001c908769] source 9336286a7ea5385541344f444e6f8702c85bdacb
Interestingly it only happens on A2 when changing to #.##0 format, but not on A1 when changing to 0 or Standard format and back to #.##0 I don't know what Writer does there. Might be it feeds the formatted string to the expression, which would be wrong, but that doesn't fit with that it doesn't happen on A1.
Still persistent with 7.0.1 portable. Just in case someone reading this needs a workaround: - define variable in an empty unused cell, use formatting without grouping (thousand separator) - set the text color of that cell to white, so this number does not get printed - in the cell where the number is supposed to be shown, use a table reference to the cell with the variable, format this cell with thousands separator, done
Dear Daniel Frost, 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
The bug is still present as described above, tested with Version: 7.3.6.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 1:7.3.6-0ubuntu0.22.04.2 Calc: threaded
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/29f5742bc8ff36741baac5b71082b3daee70ac18 tdf#125154 i18npool,sw: fix group separators in numbers in formulas It will be available in 24.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.
fixed on master (the group separator will be recognized if followed by 3 digits) what happens with cell A1 in the attached is not obvious: there are actually *2* fields in the cell, and the 1st one is hidden - and Writer only evaluates the 1st field in a table cell to get the cell value. so the field you're editing in the UI isn't actually used.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/1bd9a51b826015746069fcc0d02a30a2ddc7e7f5 tdf#125154 i18npool,sw: fix group separators in numbers in formulas It will be available in 7.5.5. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/38fc8636e4e7a79bbf59acea05f188220f22cf95 tdf#125154 i18npool,sw: fix group separators in numbers in formulas It will be available in 7.6.0.0.beta2. 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.
(In reply to Michael Stahl (allotropia) from comment #9) > fixed on master (the group separator will be recognized if followed by 3 > digits) > > what happens with cell A1 in the attached is not obvious: there are actually > *2* fields in the cell, and the 1st one is hidden - and Writer only > evaluates the 1st field in a table cell to get the cell value. > > so the field you're editing in the UI isn't actually used. Confirm. After deleting this hidden field, recalculation works well. But there is another issue: recalculation is triggered only by clicking on a table or moving the writing cursor by keyboard arrows into it. So it looks like in large documents we would be forced to click each table to recalculate them. For me, it's still a 'bug-behavior'. Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: CL threaded