Jump to content
dummzeuch

TFormatSettings.ListSeparator

Recommended Posts

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

 

Customise_Format.thumb.png.71bf67120d12f80dbbc2151df11d4a6b.png

 

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. 😉 )

Share this post


Link to post
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+).

  • Like 1
  • Thanks 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×