How to call EnumSystemLocales in Delphi?

Question

i am trying to call EnumSystemLocales in Delphi. For example:

{ Called for each supported locale. }
function LocalesCallback(Name: PChar): BOOL; stdcall;
begin
   OutputDebugString(Name);
   Result := Bool(1); //True
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
   EnumSystemLocales(@LocalesCallback, LCID_SUPPORTED);
end;

The problem is that the callback is only being called once.

Note: EnumSystemLocales is returning true, indicating success.

The remarks of EnumSystemLocales says that my callback must return true to continue enumerating (or more correctly, must not return false to continue enumerating):

The function enumerates locales by passing locale identifiers, one at a time, to the specified application-defined callback function. This continues until all of the installed or supported locale identifiers have been passed to the callback function or the callback function returns FALSE.

On the documentation of the callback function:

BOOL CALLBACK EnumLocalesProc(
  __in  LPTSTR lpLocaleString
);

a commenter has come across a problem with the definition of "not false":

This function must return 1, not (DWORD) -1 to continue processing

This makes me think that delphi's definition of

True: BOOL;

is different than Window's. (That's why i tried a return value of BOOL(1) - which still fails).

Next i wonder if it's not even supposed to be stdcall.

Either way, can someone suggest how, in Delpi, to call EnumSystemLocales?

---

Edit: Also tried:

• Result := BOOL(-1);
• Result := BOOL($FFFFFFFF);
• Result := BOOL(1);
• Result := True;

Despain

The problem seems to be focused on the manner to write the callback function rather than calling EnumSystemLocales. Am I right? – Apex

@Apex It very well might be - but i don't want to discount any possiblity. – Despain

It may also have to do with Windows, I use Delphi XE and encounter all the issues mentionned. Any similar feedback ? – Apex

Answer 1

try declarating the LocalesCallback function like this

function LocalesCallback(Name: PChar): Integer; stdcall;

check this sample

{$APPTYPE CONSOLE}

{$R *.res}

uses
  Windows,
  SysUtils;

function LocalesCallback(Name: PChar): Integer; stdcall;
begin
   Writeln(Name);
   Result := 1;
end;

begin
  try
    EnumSystemLocales(@LocalesCallback, LCID_SUPPORTED);
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

Maebashi

@Apex - It's a workaround for missing/incompatible data type in the language. See qc.embarcadero.com/wc/qcmain.aspx?d=72852 – Leadbelly

@menjaraz, yes it is a workaround, and rather ugly for my taste. See my answer for background details. – Door

Funny, FPC had similar problems in spring with (mostly) GTK. Now has boolean8/16/32. – Cantwell

Sorry for the late accept; i upvoted and commented, but forgot the most important step. – Despain

Answer 2

This problem happens due WinAPI bug, observed in Windows version 5.1 WinNls EnumXXX function family (and, according to the comments, probably several others) is only recognizing exactly (BOOL)1 as (BOOL)TRUE and will stop enumeration if callback returns any other returnValue != (BOOL)FALSE.

Here is a most semantic workaround i figured out:

  LongWord(Result) := LongWord(True);     // WINBUG: WinNls functions will continue
                                          // enumeration only if exactly 1 was returned
                                          // from the callback

Door

Problem is that there's so many booleans to choose from (blogs.msdn.com/b/oldnewthing/archive/2004/12/22/329884.aspx) – Despain

@IanBoyd, not really, our primary documentation source clearly states which type we (client developers) must use. Problem is what NLS subsytem doesnt follow its own rules. And what mr. Chen unwillingly confirms in his diary - is what MS project managers failed to coordinate common style amongst teams, allowing described type zoo to spread over code-base. – Door

Answer 3

If you insist on using BOOL type for callback function result, use this:

function LocalesCallback(Name: PChar): BOOL; stdcall;
begin
   OutputDebugString(Name);
   LongWord(Result) := 1;
end;

because Bool(1) = $FFFFFFFF.

Knesset

Is that a workaround or is there a compiler issue on casting to BOOL type ? – Apex

AFAIK in old C the type BOOL was Integer type, and true = !false; since false = 0, that means true = not 0 = $FFFFFFFF (assuming sizeof(bool) = 4). That is my guess, I may be wrong. – Knesset

C has no boolean type till C99. INT (Integers) can be tested without == though, and then the semantic you name are valid (false=0 true =!false). But APIs have different conventions. GTK GBoolean is the same. They are actually closer to the Pascal boolean type, but that exists in Delphi as 8 bits variant only. – Cantwell

@Serg i wasn't really insisting on using BOOL. The Win32 API says BOOL (which it also says is typedef int BOOL;). i just assumed Delphi's BOOL (which is Windows.BOOL = LongBool;) was compatible with Window's BOOL. – Despain