Hi Regina,
On 9/3/25 18:22, Regina Henschel wrote:
Hi Kohei,
Kohei Yoshida schrieb am 23.08.2025 um 03:21:
[..]
It should be fairly trivial to implement the integer mode since all
you have to change is to not allow the decimal separator to be parsed
as a digit character. Here
https://git.libreoffice.org/core/+/refs/heads/master/sc/source/core/data/table3.cxx#119
is where the code retrieves the decimal separator character for the
current locale and plug that into the token parser. Passing an empty
string in lieu of that may be enough to implement the integer mode
(in theory.. please test this!).
I have tried it with manually set values for the parameters of
parsePredefinedToken(). The tests include empty string instead of
sUser, KParseToken::ANY_DIGIT and KParseType::ASC_NUMBER. None of the
tests work. It seems, that the parsePredefinedToken method always uses
the decimal separator that it receives from the Locale of its CharClass.
Yup, I confirm that. I guess I was too optimistic in making that
suggestion. ;-) If that's the case, I wonder what is the point of
passing that decimal separator to parsePredefinedToken() there... Eike
would probably know more about this, for sure.
Just to satisfy my own curiosity, I hunted down the location of the
implementation of this function, and it's here:
https://git.libreoffice.org/core/+/refs/heads/master/i18npool/source/characterclassification/cclass_unicode.cxx#261
and the bulk of the parsing is done in this function (parseText):
https://git.libreoffice.org/core/+/refs/heads/master/i18npool/source/characterclassification/cclass_unicode_parser.cxx#727
If you take a look at line 1091 of this file, you see this:
r.Value=::rtl::math::stringToDouble(aTmp,cDecimalSep,cGroupSep );
which confirms your observation. There is similar stuff on line 1072 too.
If you hack this function and manually assign 0 to cDecimalSep, the code
ignores the decimal separator and you can effectively achieve an integer
mode. Extending the XCharacterClassification interface to support
integer mode is in theory achievable, though that would be quite some
effort...
That would mean, that a natural sort of type 'integer' needs its own
method 'SplitStringInteger'.
I guess so, if you decide to not use the XCharacterClassification API.
Kohei
