Bug 123878 - Numeric format inconsistency: Macros vs Writer fields, formula calculation fails
Summary: Numeric format inconsistency: Macros vs Writer fields, formula calculation fails
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Extensions (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Macro
  Show dependency treegraph
 
Reported: 2019-03-05 15:50 UTC by jsd.libreoffice
Modified: 2019-04-19 14:10 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jsd.libreoffice 2019-03-05 15:50:40 UTC
[Sorry if Extensions component is wrong, wasn't sure what to pick]

Running LO 6.2.0.3 on MacOS 10.13.6 in South Africa, where system regional setting uses comma rather than period for decimal separator.

Writer treats strings with period, eg "1.5" as non-numeric and evaluates that as 0.  With a comma instead, eg "1,5" the value is one-and-a half. OK, fair enough.

Now I have a macro that extracts a value from a spreadsheet cell, and sets that value into a Writer variable field which is then used elsewhere in a Writer formula.

The latter formula does not compute correctly - result is 0 - because the extracted spreadsheet value (a floating point number, type Variant/Double returned by RangeTLCellValue) gets turned into a string with a period for decimal point in the Writer variable field (DependentTextField.Content = myNumericValue)

Either the implicit double-to-string conversion should be using the same punctuation that's expected elsewhere (so comma not period) or else everything should accept a period as decimal separator in number strings, and then do the local-dependent presentation only at the formatting stage (which is what OpenOffice used to do: this macro began life there).

FWIW I tried changing Language settings in the document, made no difference.  Presumably the system locale trumps that for number parsing.  This also affected static "set variable" fields in the template: I had to change decimal periods to commas in those too, to make the formulas work.