TFormatSettings.ListSeparator

[dummzeuch 1505]

TFormatSettings.ListSeparator is supposed to return the character the user has configured in the Windows configuration dialog:

 

 

This works fine if it only contains a single character, which at least the possible selections for English (UK / US) and German (Germany) actually are:

';' and ','.

 

But this dialog also allows to enter any string as the list separator, e.g. 'asdf' which will cause TFormatSettings.ListSeparator to return ','.

 

The reason is that it gets filled calling GetLocaleInfo with a buffer size of 2 (in Chars) which will return 0 because the buffer is too small:

function GetLocaleChar(Locale, LocaleType: Integer; Default: Char): Char;
var
  Buffer: array[0..1] of Char;
begin
  if GetLocaleInfo(Locale, LocaleType, Buffer, 2) > 0 then
    Result := Buffer[0] else
    Result := Default;
end;

This will then set Result to the Default parameter (which is ',').

 

Is this a bug or a documented feature? I couldn't find any documentation on it.

 

If it's a bug, of course the question is, what should it do instead? Since TFormatSettings.ListSeparator is a Char, it cannot return more than one characters.

 

Are there any locales where a list separator with more than one character is commonly used? E.g. Chinese ? (I always suspect the Chinese to do something unexpected. 😉 )

[Stefan Glienke 2002]

[Remy Lebeau 1393]

4 hours ago, dummzeuch said:

Is this a bug or a documented feature? I couldn't find any documentation on it.

The List Separator is expected to be 1 character, but is documented to allow up to 3 characters:

Quote

Character(s) used to separate list items, for example, a comma is used in many locales. The maximum number of characters allowed for this string is four, including a terminating null character.

4 hours ago, dummzeuch said:

Are there any locales where a list separator with more than one character is commonly used? E.g. Chinese ? (I always suspect the Chinese to do something unexpected. 😉 )

Doubtful, but the API is probably intended to handle MBCS characters, which I would expect the API to convert into proper UTF-16 characters when queried (and hopefully they fall into the U+0000..U+FFFF range so they fit into a single Char in Delphi 2009+).