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)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Tables-Formulas
  Show dependency treegraph
Reported: 2019-05-07 12:43 UTC by D.F.
Modified: 2019-08-11 09:40 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

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

Note You need to log in before you can comment on or make changes to this bug.
Description D.F. 2019-05-07 12:43:13 UTC
using Libre Office portable

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 D.F. 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: (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

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: (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:


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.

$ 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.