9

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;
Ian Boyd
  • 246,734
  • 253
  • 869
  • 1,219
  • The problem seems to be focused on the manner to write the callback function rather than calling EnumSystemLocales. Am I right? – menjaraz Dec 23 '11 at 16:08
  • @menjaraz It very well might be - but i don't want to discount any possiblity. – Ian Boyd Dec 23 '11 at 17:40
  • It may also have to do with Windows, I use Delphi XE and encounter all the issues mentionned. Any similar feedback ? – menjaraz Dec 23 '11 at 18:01

3 Answers3

9

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.
RRUZ
  • 134,889
  • 20
  • 356
  • 483
4

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
OnTheFly
  • 2,059
  • 5
  • 26
  • 61
  • 1
    Problem is that there's so many booleans to choose from (http://blogs.msdn.com/b/oldnewthing/archive/2004/12/22/329884.aspx) – Ian Boyd Dec 23 '11 at 17:45
  • 1
    @IanBoyd, not really, our [primary documentation source](http://msdn.microsoft.com/en-us/library/windows/desktop/dd317822%28v=vs.85%29.aspx) 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. – OnTheFly Dec 23 '11 at 18:21
2

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.

kludg
  • 27,213
  • 5
  • 67
  • 118
  • Is that a workaround or is there a compiler issue on casting to BOOL type ? – menjaraz Dec 23 '11 at 16:04
  • 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. – kludg Dec 23 '11 at 16:42
  • 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. – Marco van de Voort Dec 23 '11 at 17:33
  • @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`. – Ian Boyd Dec 23 '11 at 17:44