EnumChildWindows wird nicht aufgerufen

[Christian Seehase]

Moin Zusammen,

ich erstelle gerade ein kleines Konsolenprogramm (soll unter XP laufen), dass ein Programm aufrufen, und dann einen Button dieses Programmes anklicken soll.
Das funktioniert auch alles, ausser das aufgerufene Programm maximiert sich durch ein
SendMessage(self.Handle,WM_SYSCOMMAND,SC_MAXIMIZE, 0);
im OnCreate (ein SC_MINIMIZE bringt das Problem nicht)
Dann wird nur das Hauptfenster gefunden, und EnumChildWindows wird nicht aufgerufen.

Delphi-Quellcode:

function GetButtonHandle(const AhProcess : DWORD;const AsButtonText : string) : DWORD;


var
  dwPID : DWORD;

begin
  Result      := $FFFFFFFF;
  dwPID       := GetProcessId(AhProcess);
  hMainWindow := 0;
  EnumWindows(@EnumWindowsProc,dwPID);
  if hMainWindow = 0 then Exit;
  hButtonToClick := 0;
  sButtonText    := AsButtonText;
  AttachThreadInput(GetCurrentThreadID,GetWindowThreadProcessID(hMainWindow,nil),true);
  try
  if not EnumChildWindows(hMainWindow,@EnumChildWindowsProc,0) then begin
//    ShowMessage(SysErrorMessage(GetLastError));
  end;
  finally
    AttachThreadInput(GetCurrentThreadID,GetWindowThreadProcessID(hMainWindow,nil),false);
  end;
  if hButtonToClick = 0 then begin
    Result := 0;
  end else begin
    Result := hButtonToClick;
  end;
end;

ShowMessage meldet dann fleissig, dass der Vorgang erfolgreich beendet wurde.

Hat jemand eine Idee, warum die Funktion nicht aufgerufen wird?

[CCRDude]

Wenn es nicht aufgerufen wird, würde ich mit dem Debugger durchsteppen, evtl. wirft AttachThreadInput eine Exception?

Oder Du meinst eigentlich, dass EnumChildWindows false zurückgibt. Dann würde ich in der MSDN nach Ursachen schauen und dort sehen, dass der Rückgabewert gar nicht genutzt wird und daher wohl nicht definiert ist.

Zuletzt könnte ich noch interpretieren, dass nicht EnumChildWindows, sondern EnumChildWindowsProc nicht aufgerufen wird. In dem Fall wäre der Code von EnumChildWindowsProc hilfreich.

[Christian Seehase]

Moin,

danke.
Du hast recht, ich meinte natürlich EnumChildWindowsProc

Delphi-Quellcode:

function EnumChildWindowsProc(const AhWindow : DWORD;const AlParam : DWORD) : Longbool; stdcall;

var
  dwTextLength : DWORD;
  pBuf         : PChar;
  sText        : string;

begin
  Result := true;
//  SetLastError(2);
  //TODO: Ggf. noch mit GetClassName noch auf Klasse Button prüfen.
  dwTextLength := SendMessage(AhWindow,WM_GETTEXTLENGTH,0,0);
  Inc(dwTextLength);
  pBuf := AllocMem(dwTextLength);
  try
    SendMessage(AhWindow,WM_GETTEXT,dwTextLength,LParam(pBuf));
    sText := Trim(pBuf);
  finally
    FreeMem(pBuf,dwTextLength);
  end;
  Result := not (AnsiCompareText(sText,Trim(sButtonText)) = 0);
  if not Result then begin
    hButtonToClick := AhWindow;
//    SetLastError(5);
  end;
end;

Die SetLastError-Zeilen dienten nur zu Testzwecken um festzustellen, wie weit die Routine abgearbeitet wird. Sie haben keine Änderung des Verhaltens mit sich gebracht.

[CCRDude]

Muss gerade leider den Rechner neu aufsetzen und kann nicht viel probieren (werd das später evtl. mal probieren, wenn's dann noch offen ist), habe aber mal in meinen Code geschaut, weil ich EnumChildWindows auch an zwei Stellen einsetze. Einziger Unterschied: ich verwende kein const für die Parameter - finde auch in der MSDN keinen Hinweis darauf.

Code:

BOOL CALLBACK EnumChildProc(
  _In_  HWND hwnd,
  _In_  LPARAM lParam
);

Aber - dann würde es ja nie statt nur in dieser speziellen Situation nicht funktionieren.

[Christian Seehase]

Moin,

bei API-Funktionen, besser C(++)-Funktionen, verwende ich grundsätzlich const, um gar nicht erst in die Verlegenheit zu kommen, nil nicht als Wert übergeben zu können
Ausserdem habe ich diese Konstellation auch schon öfter verwendet (auch bei EnumChildWindowsProc), ohne dass es zu Problemen gekommen wäre.