https://bz.apache.org/ooo/show_bug.cgi?id=82687
--- Comment #9 from [email protected] --- The problem begins in ImpSvNumberInputScan::NextNumberStringSymbol() of file main/svl/source/numbers/zforfind.cxx, where in state SsGetString, all non-digits are concatenated into one string. Since ImpSvNumberInputScan:NextNumberStringSymbol() is used by ImpSvNumberInputScan::NumberStringDivision(), the string "$.1" is parsed into ["$.", "1"] while "$0.1" is parsed into ["$", "0", ".", "1"] Patching ImpSvNumberInputScan:NextNumberStringSymbol() as follows: ---snip--- diff --git a/main/svl/source/numbers/zforfind.cxx b/main/svl/source/numbers/zforfind.cxx index de98a1c68f..a5330cba38 100644 --- a/main/svl/source/numbers/zforfind.cxx +++ b/main/svl/source/numbers/zforfind.cxx @@ -277,7 +277,7 @@ sal_Bool ImpSvNumberInputScan::NextNumberStringSymbol( } break; case SsGetString: - if ( !MyIsdigit( cToken ) ) + if ( !MyIsdigit( cToken ) && ((char)cToken) != '.' ) nChars++; else { ---snip--- causes "$.1" to then get parsed into ["$", ".", "1"], which correctly gets detected as a numerical format, but is wrongly parsed elsewhere, becoming "$1.00" instead of "$0.10". So it appears there are at least 2 bugs: 1. Decimal separators are not separated from currency symbols, causing currency symbol detection to fail, and the field wrongly becomes a string. 2. Even if that is fixed, when the number starts with ".", the "." is ignored and the number is parsed incorrectly. That patch is not fully correct anyway, as decimal separators are locale-sensitive. -- You are receiving this mail because: You are the assignee for the issue. You are on the CC list for the issue.
