Bug 125154 - writer calculation using variable within table does not work with formated numbers
Summary: writer calculation using variable within table does not work with formated nu...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.2.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Tables-Formulas
  Show dependency treegraph
 
Reported: 2019-05-07 12:43 UTC by Daniel Frost
Modified: 2020-09-25 05:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
writer doc with table and variable showing issue (9.59 KB, application/vnd.oasis.opendocument.text)
2019-05-07 12:44 UTC, Daniel Frost
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Frost 2019-05-07 12:43:13 UTC
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
Comment 1 Daniel Frost 2019-05-07 12:44:25 UTC
Created attachment 151216 [details]
writer doc with table and variable showing issue
Comment 2 Oliver Brinzing 2019-05-07 18:51:10 UTC
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:
Comment 3 Oliver Brinzing 2019-05-08 16:40:33 UTC
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 sha:e45c30858dec1dd705b9144fab981a3c8819ba96
# good: [b0a56ec98b1368cb5e3e531e0b3f69565af91609] source sha:3a801799536e6870f2fb111b1cc00b9575a35a39
git bisect start 'master' 'oldest'
# good: [5180a3b7a5dc530ad7ec5bd6e5cefecf85beab7e] source sha:8bcc4a98d78869d6839821b9747602777f00ebaf
git bisect good 5180a3b7a5dc530ad7ec5bd6e5cefecf85beab7e
# good: [1473ee9b216ec27c5410a08036aef0a4b857841c] source sha:93c817971d76ff5020d4210229896a35d357a371
git bisect good 1473ee9b216ec27c5410a08036aef0a4b857841c
# good: [9fbd095c4236de2f48da51d83c976a942dfa6a31] source sha:8ff55c16e853600fdac6164d34ff35421a1f112e
git bisect good 9fbd095c4236de2f48da51d83c976a942dfa6a31
# good: [27454ec8bb96a7fc768bddfcf7e19099936d098a] source sha:9553f2afd0527ba435dae7bf4506c620a943b150
git bisect good 27454ec8bb96a7fc768bddfcf7e19099936d098a
# good: [94eecb1ddc570e0f8c253b2d48d415cca763d228] source sha:1d988778095ecbe84f1a1002511377d0708b3443
git bisect good 94eecb1ddc570e0f8c253b2d48d415cca763d228
# good: [69d20cfa5cb1238bb15feb4149c0e362b808f008] source sha:4b7cbb569e52e483a5edda8afe27d423e428edbb
git bisect good 69d20cfa5cb1238bb15feb4149c0e362b808f008
# good: [3468d19ea957918870481bfc9f82a9b80c76ca69] source sha:6e8605ee6de4ead23925476f0e945b51dea26be0
git bisect good 3468d19ea957918870481bfc9f82a9b80c76ca69
# good: [db592044a1d82ff045cf753f5f05000b3d3533ab] source sha:9766892044fc69de18d0395ec2c4a0e652165c23
git bisect good db592044a1d82ff045cf753f5f05000b3d3533ab
# bad: [fa3f1cbd5e495466aad8b5bce09143691ea08b69] source sha:4490d4edcff54e439ee3e97b5ce88dc3f065881b
git bisect bad fa3f1cbd5e495466aad8b5bce09143691ea08b69
# good: [a46cc254e889043f93c8029a092e039b77bc1148] source sha:f8c76ab81bb5b443c5077c2cac9112f8e0ee6855
git bisect good a46cc254e889043f93c8029a092e039b77bc1148
# bad: [c17fbd5031acd0c942669d81213488001c908769] source sha:9336286a7ea5385541344f444e6f8702c85bdacb
git bisect bad c17fbd5031acd0c942669d81213488001c908769
# good: [8f6028efc3319237e74bdc7b79ba2ae588c69d70] source sha:4632afbd9ecdf85f3980b41fa9d58b6099aa2d81
git bisect good 8f6028efc3319237e74bdc7b79ba2ae588c69d70
# first bad commit: [c17fbd5031acd0c942669d81213488001c908769] source sha:9336286a7ea5385541344f444e6f8702c85bdacb
Comment 4 Eike Rathke 2019-05-09 11:57:06 UTC
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.
Comment 5 Daniel Frost 2020-09-25 05:51:56 UTC
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