Hi, To solve https://bugs.documentfoundation.org/show_bug.cgi?id=42518 where in a Writer table formula a group separator entered instead of the intended decimal separator lead to wrong calculations instead of error, the css::i18n::KParseTokens constants have a new bit added, GROUP_SEPARATOR_IN_NUMBER. This changes the runtime behaviour of calls to css::i18n::XCharacterClassification::parseAnyToken() and parsePredefinedToken() that do not have the bit set, citing from the description documentation in offapi/com/sun/star/i18n/KParseTokens.idl: If this bit is set in <em>nContCharFlags</em> parameters, the locale's group separator characters in numbers are accepted and ignored/skipped. Else a group separator in a number ends the current token. A leading group separator is never accepted. If an accepted group separator was encountered in a number (ParseResult::TokenType is KParseType::ASC_NUMBER or KParseType::UNI_NUMBER) this bit is also set in ParseResult::ContFlags. <p> <strong>NOTE:</strong> absence of this bit in <em>nContCharFlags</em> changes the default behaviour that in prior releases accepted numbers with group separators but lead to unexpected results when parsing formula expressions where the user entered a (wrong) separator that happened to be the group separator instead of an intended decimal separator. Usually inline numbers in a formula expression do not contain group separators. The default for this flag instead of a negated default (continue to parse away group separators if not set) was chosen because of that formula expression context mentioned in the description, which this parser is usually used for. Happy parsing Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Attachment:
signature.asc
Description: PGP signature