EnumWindowsProc -> EAccessError, OutOfResources

[Jonas]

Heya. Ich versuche aus bestimmten Fenstern Buttons zu erstellen, was an sich auch recht gut klappt. Um auch immer die aktuellen Fenster in meinem Pogramm darzustellen, habe ich meine Procedure in einen Timer gegeben. Ich bekomme jedoch sobald man ein neues Fenster öffnet einen EAcessError oder ab und an auch einen OutOfResources. Ich habe bereits des öfteren nach meinem Fehler gesucht, kam auch immer zu einer bestimmten Zeile, welche ich anschließend wegestrichen hab um den kompletten Fehlerhaften Code zu erkennen. Jedoch kam ich schlussendlich nur noch zur Zeile 'application.run' und nun weiss ich irgendwie nicht mehr weiter. Darum wollte ich hier um Hilfe bitten.

Delphi-Quellcode:

procedure TTaskbar.Tasks();
var
i: Integer;

Function EnumWindowsProc(Wnd: THandle): BOOL; StdCall;
Var
  Capt: Array [0..128] of Char;
Begin
  Result:=true;
  If IsWindowVisible(Wnd) and
     ((GetWindowLong(Wnd, GWL_HWNDPARENT)=0) or
      (HWND(GetWindowLong(Wnd, GWL_HWNDPARENT))=GetDesktopWindow)) and
     ((GetWindowLong(Wnd, GWL_EXSTYLE) and WS_EX_TOOLWINDOW)=0)
  then
  begin
    SendMessage(Wnd, WM_GETTEXT, Sizeof(Capt), integer(@Capt));
    //angezeigt bis 13. Buchstabe//
    Capt[13] := Chr( 0 );
    SetLength(FensterInfo, length(FensterInfo)+1);
    inc(lengthvar);
    FensterInfo[High(FensterInfo)].Caption:=Capt;
    FensterInfo[High(FensterInfo)].Handle:=Wnd;
  end;
end;

begin
  SetLength(FensterInfo, 0);
  EnumWindows(@EnumWindowsProc, 0);

  if oldCount <> high(FensterInfo) then begin

    oldCount := high(FensterInfo);
    for i := 0 to high(Blabel) do
    Blabel[i].Free;
    for i := 0 to high(task) do
    task[i].Free;
    for i := 0 to high(taskicon) do
    taskicon[i].Free;



for i := 0 to Length(FensterInfo) - 1 do
begin
taskhandle[i]:= FensterInfo[I].Handle;
end;

for i := 0 to Length(FensterInfo) - 1 do
begin
task[i]:= TImageEx.Create(nil);
with task[i] do
        begin
             Parent := Taskbar;
             Picture.Bitmap.LoadFromResourceName(imageresDLL, 'task_normal');
             Height := 26;
             Width := 100;
             Top := 12;
             Transparent := true;
             Stretch := true;
             if i <> 0
             then Left := (i * 102) + 63
             else Left := (i * 102) + 63;
             Tag := i;
             OnClick := TaskClick;
             OnMouseEnter := TaskOver;
            OnMouseLeave := TaskNormal;
             Show;
             //Repaint
        end;
end;

for i := 0 to Length(FensterInfo) - 1 do
begin
  Blabel[i] := TLabel.Create(nil);
with  Blabel[i] do
        begin
             Parent := Taskbar;
             Enabled := true;
             AutoSize := false;
             Caption := taskpunkt(FensterInfo[i].Caption);
             Height := 27;
             Width := 74;
             Top := 19;
             visible := true;
             Color := clFuchsia;
             ParentColor := False;
             Transparent := True;
             Font.Color := clwhite;
             //OnClick := TaskClick;
             //OnMouseEnter := TaskOver;
             //OnMouseLeave := TaskNormal;
              if i <> 0
             then Left := (i * 102) + 87 // Width * i + (i-2)*Height
             else Left := (i * 102) + 87;
  end;
end;
  end;
end;

Ich bin irgendwie der Meinung, dass der Fehler nicht an der Procedure selbst, sondern eher an der funktion liegt.

[Jonas]

Hat keine ne Idee? :(

[Muetze1]

Wie kommst du auf die Idee, dass die EnumWindows() zu übergebene Callback Procedure nur einen Parameter hat? Damit zerschiesst du den gesamten Stack!

Zitat:

Zitat von MSDN

BOOL CALLBACK EnumWindowsProc(

HWND hwnd,
LPARAM lParam
);

Schau in die MSDN EnumWindowsProc und EnumWindows()

[himitsu]

Und sollte Delphi nicht wegen der lage der EnumWindowsProc meckern?

bei mir hatte der es jedenfalls gemacht, als ich sowas versucht habe habe?

Also die Procedur in einer anderen eingebettet war ... es meinte ich solle die gefälligst inzeln ablegen ._.

[Muetze1]

Zitat:

Zitat von himitsu

Und sollte Delphi nicht wegen der lage der EnumWindowsProc meckern?

bei mir hatte der es jedenfalls gemacht, als ich sowas versucht habe habe?

Also die Procedur in einer anderen eingebettet war ... es meinte ich solle die gefälligst inzeln ablegen ._.

Ja, richtig, das kommt noch erschwerend hinzu. Und da wird die Typensicherheit die Delphi eigentlich so auszeichnet und sogar für Anfänger nutzbar macht wieder umgangen - mit einem @Zeichen...

Was soll man dazu noch sagen...

[himitsu]

Zitat:

Zitat von Muetze1

Ja, richtig, das kommt noch erschwerend hinzu. Und da wird die Typensicherheit die Delphi eigentlich so auszeichnet und sogar für Anfänger nutzbar macht wieder umgangen - mit einem @Zeichen...

jetzt wo du das sagst ... ich hab ja in meiner eigenen implementation (nutze nicht die windows.pas) wohl etwas anders gemacht.
ich kann mich jedenfalls nicht erinnern bei mir ein @ benötigt zu haben (außer halt bis auf das eine Mal, wo ich eine Prozedur in 'ner anderen "absichtlich" eingelagert hatte) ._.

ich hab es jedenfalls so wie es im MSDN drinsteht gemacht und soweit ich das sah geht da Borland manchma seinen eigenen Weg ^^

[Jonas]

Zitat:

Zitat von himitsu

Und sollte Delphi nicht wegen der lage der EnumWindowsProc meckern?

bei mir hatte der es jedenfalls gemacht, als ich sowas versucht habe habe?

Also die Procedur in einer anderen eingebettet war ... es meinte ich solle die gefälligst inzeln ablegen ._.

Wieso wegen der Lage? Also bei mir meckert Delphi ganz und gar nicht.

Okay das mit dem 2. Parameter wusste ich nicht, muss es mal probieren.

[Muetze1]

Zitat:

Zitat von Jonas

Wieso wegen der Lage? Also bei mir meckert Delphi ganz und gar nicht.

Auch die restlichen Post gelesen und - ganz wichtig - verstanden ?

Ich zitiere hier nochmal das wichtigste...

Zitat:

Zitat von himitsu

Und sollte Delphi nicht wegen der lage der EnumWindowsProc meckern?

...

Also die Procedur in einer anderen eingebettet war ... es meinte ich solle die gefälligst inzeln ablegen ._.

Zitat:

Zitat von Muetze1

Ja, richtig, das kommt noch erschwerend hinzu. Und da wird die Typensicherheit die Delphi eigentlich so auszeichnet und sogar für Anfänger nutzbar macht wieder umgangen - mit einem @Zeichen...

Übersetzt nocheinmal für dich:

Er sollte meckern, da man keine lokalen Procedure als CallBack Funktionen übergeben darf. Und er meckert bei dir nicht, da du die Typensicherheit (die Typprüfung würde schliesslich meckern bei lokalen Proceduren als Parameter) mit dem @ Zeichen umgangen hast. Durch das @ Zeichen ermittelst du einen Pointer auf die Procedure und somit wird die gesamte Prüfung hinfällig. Ein Pointer ist ein Pointer und da kann man keine Procedure mit einer benötigten Parameterliste draus herauslesen. Versuch du mal bei einem Packet ohne Aufkleber und Text unbekannter Herkunft den Inhalt zu erraten, ohne das Packet zu öffnen.

Alle Sicherheitsmerkmale die Delphi in der Beziehung bietet, hast du umgangen, somit ist es kein Wunder das er...

a) abstürzt
b) nicht meckert

[Jonas]

Zitat:

Er sollte meckern, da man keine lokalen Procedure als CallBack Funktionen übergeben darf.

Huh? Das check ich nicht so ganz?


Hier mal meine überarbeitete Version der funktion

Delphi-Quellcode:

 Und er meckert bei dir nicht, da du die Typensicherheit (die Typprüfung würde schliesslich meckern bei lokalen Proceduren als Parameter) mit dem @ Zeichen umgangen hast.

Das ist mit mittlerweile klar, nur ohne dieses @ zeichen, also ohne umgehen der Typsicherheit, funktioniert es ja nicht. Ich meine bei

Delphi-Quellcode:

begin
SetLength(Arr, 0);
EnumWindows(@EnumWindowsProc, DWORD(@arr));

@EnumWindowsProc kommt dann nicht genügend wirkliche Parameter und bei @arr ohne @ kann ich es zwar noch kompilieren, werde dann aber direkt in die zeile

Delphi-Quellcode:

    SetLength(arr^, length(arr^)+1);

geschmissen, nachdem das Programm noch nichtmals richtig erschienen ist.

Delphi-Quellcode:

 type
   TFensterInfo=record
     Handle: HWND;
     Caption: String;
     Icon: HIcon;
   end;
 FensterInfo= array of TFensterInfo;
 PFensterInfo= ^FensterInfo;

var
  lengthvar: integer = 0;
  oldCount: Integer;

function EnumWindowsProc(Wnd: HWND; lp: LPARAM): BOOL; stdcall;
Var
  Capt: Array [0..128] of Char;
  arr: PFensterInfo;
Begin
  Result:=true;
  arr := PFensterInfo(lp);

  If IsWindowVisible(Wnd) and
     ((GetWindowLong(Wnd, GWL_HWNDPARENT)=0) or
      (HWND(GetWindowLong(Wnd, GWL_HWNDPARENT))=GetDesktopWindow)) and
     ((GetWindowLong(Wnd, GWL_EXSTYLE) and WS_EX_TOOLWINDOW)=0)
  then
  begin
    SendMessage(Wnd, WM_GETTEXT, Sizeof(Capt), integer(@Capt));
    //angezeigt bis 13. Buchstabe//
    Capt[13] := Chr( 0 );
    SetLength(arr^, length(arr^)+1);
    inc(lengthvar);
    arr^[High(arr^)].Caption:=Capt;
    arr^[High(arr^)].Handle:=Wnd;
  end;
end;

procedure TForm2.Tasks();
var
i: Integer;
arr: FensterInfo;
begin
SetLength(Arr, 0);
EnumWindows(EnumWindowsProc, DWORD(@arr));
// für den teil siehe oben //
end;

[Muetze1]

Ok, ich habe mich geirrt in 2 Dingen:

1. Die EnumWindowProc darf doch lokal sein!
2. EnumWindows() ist bei D5 u.a. noch so definiert, dass die EnumWindowProc als Pointer definiert wurde und nicht als Procedure Prototype.

Hier ein funktionierender Code:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls;

type
  TForm1 = class(TForm)
    ListBox1: TListBox;
    procedure FormShow(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

type
  TFensterInfo = record
    Handle: HWND;
    Caption: String;
    Icon: HIcon;
  end;
  PFensterInfoList = ^TFensterInfoList;
  TFensterInfoList = Array Of TFensterInfo;

Var
  WindowList: TFensterInfoList;

Function EnumWindowsProc(Wnd: HWND; lp: LPARAM): LongBool; stdcall;
Const
  coBufferSize = 2048;
Var
  lList: PFensterInfoList;
  lCaption: String;
  lCapLen: Integer;
Begin
  Result := True;
  lList := PFensterInfoList(lp);

  If IsWindowVisible(Wnd) and
     ((GetWindowLong(Wnd, GWL_HWNDPARENT)=0) or
      (HWND(GetWindowLong(Wnd, GWL_HWNDPARENT))=GetDesktopWindow)) and
     ((GetWindowLong(Wnd, GWL_EXSTYLE) and WS_EX_TOOLWINDOW)=0) then
  begin
    SetLength(lCaption, coBufferSize);
    lCapLen := SendMessage(Wnd, WM_GETTEXT, coBufferSize, Integer(PChar(lCaption)));
    SetLength(lCaption, lCapLen);

    SetLength(lList^, Length(lList^)+1);
    lList^[High(lList^)].Caption := lCaption;
    lList^[High(lList^)].Handle  := Wnd;
  end;
end;

procedure Tasks();
Begin
  SetLength(WindowList, 0);

  EnumWindows(@EnumWindowsProc, Integer(@WindowList));
End;

procedure TForm1.FormShow(Sender: TObject);
Var
  i: Integer;
begin
  Tasks;

  For i := Low(WindowList) To High(WindowList) Do
    ListBox1.Items.Add(WindowList[i].Caption);
end;

end.

[Motzi]

Die Callback-Funktion für EnumWindows muss mit Hilfe eines @ übergeben werden, da TFNWndEnumProc als TFarProc und das wiederum als Pointer definiert ist (in Delphi 2005)..

Callback-Funktionen können _immer_ auch "nested" sein, ABER: der Vorteil dieser nested functions ist ja, dass man auch auf die Parameter und lokalen Variablen der übergeordneten Funktion zugreifen kann. Um dies möglich zu machen muss Delphi im Hintergrund einige Spielchen mit dem Stack anstellen. Sobald eine nested function aber als Callback übergeben wird darf man diesen Vorteil innerhalb dieser Funktion NICHT MEHR ausnutzen, da der Stack durch den Caller der Callback-Funktion ganz anders ausschaut, als wenn die Funktion direkt aus der übergeordneten Funktion aufgerufen worden wäre. Man erhält daher falsche Werte und das Ergebnis kann sich jeder selbst ausmalen...
Verzichtet man innerhalb der nested function jedoch auf solche Spielchen und gestaltet sie völlig unabhängig von der übergeordneten, so kann sie auch jederzeit als Callback verwendet werden!

Gruß, Motzi

[Jonas]

Danke für den funktionierenden Code. Löst in meiner Anwendung jedoch genau den gleichen Fehler aus. Ich werde mich morgen nochmals genauer damit befassen vielleicht liegt mein Fehler auch eher in meiner Procedure.
Ich dachte nur es wäre interessant für euch das zu erfahren ^^

Edit: Ich hab nochmal was rumprobiert und naja es funktioniert halt so lange man keine Fenster schließt. Im Grunde nicht viel anders als bei mir. Sobald man eben fenster schließt bekomm ich nen EAccesserror.

[Muetze1]

Kann es sein, das du deine Liste nicht aktualisierst in der ListBox und somit auf nicht mehr existierende Einträge zugreifst?

Schonmal die Bereichsprüfung eingeschaltet und Projekt komplett neu erzeugt?

[Jonas]

Ähm, naja ich benutz ja keine Listbox. Ich erstelle die Labels und Images ja direkt aus WindowList ohne vorher 'ne Listbox zu benutzten.

Delphi-Quellcode:

procedure TForm2.Tasks();
var
i: Integer;
begin
  SetLength(WindowList, 0);

  EnumWindows(@EnumWindowsProc, Integer(@WindowList));

  if oldCount <> high(WindowList) then begin

    oldCount := high(WindowList);
    for i := 0 to high(Blabel) do
    Blabel[i].Free;
    for i := 0 to high(task) do
    task[i].Free;
    for i := 0 to high(taskicon) do
    taskicon[i].Free;



For i := Low(WindowList) To High(WindowList) Do
begin
taskhandle[i]:= WindowList[I].Handle;
end;

For i := Low(WindowList) To High(WindowList) Do
begin
task[i]:= TImageEx.Create(nil);

Komischerweise meckert er erst wenn ich das 2. Fenster schließe.


Außerdem hab ich noch ne Frage. Wie unterscheidet sich

Delphi-Quellcode:

For i := Low(WindowList) To High(WindowList) Do

genau von

Delphi-Quellcode:

for i := 0 to Length(WindowList) - 1 do

?

[Jonas]

Auch wenn keiner mehr Antwortet ^^. Mittlerweile denke ich aufjedenfall zu wissen warum ich nach 2 min, auch ohne irgendwas getan zu haben einen OutOfResources Error bekomme. Wie ich ihn jedoch so recht beheben kann, weiss ich nicht.
Wenn man sich mal meine Procedure anschaut, welche ja in einem Timer sitzt. Das heisst sie wird alle 250ms ausgeführt. Somit würde ich ja die kompletten Timageexs und auch Labels immer wieder neu erstellen, auch wenn sich nichts tut. Ich denke, dass es dann irgendwann soo viele sind das ich einen OutOfResources Error bekomme. Bin mir jedoch nicht 100%ig sicher.
Hat jemand eine Idee wie man dieses Problem möglicherweise umgehen könnte?

[Muetze1]

Zitat:

Zitat von Jonas

Delphi-Quellcode:

  if oldCount <> high(WindowList) then begin

    oldCount := high(WindowList);

Count wäre Length() von einem Array, High() ergibt den höchsten Index, nicht die Anzahl. Count heisst aber nunmal Anzahl.

Zitat:

Zitat von Jonas

Delphi-Quellcode:

    for i := 0 to high(Blabel) do
    Blabel[i].Free;
    for i := 0 to high(task) do
    task[i].Free;
    for i := 0 to high(taskicon) do
    taskicon[i].Free;

Du gibst die Elemente frei, aber wo machst du das Array kleiner bzw. setzt es auf 0 etc? Wo ist das SetLength() ?

Zitat:

Zitat von Jonas

Außerdem hab ich noch ne Frage. Wie unterscheidet sich

Delphi-Quellcode:

For i := Low(WindowList) To High(WindowList) Do

genau von

Delphi-Quellcode:

for i := 0 to Length(WindowList) - 1 do

?

Gar nicht in dem Sinne. Du benutzt dynamische Arrays und die sind immer 0-basierend beim Index. Daher wäre von 0 bis Length()-1 das gleiche. Ich verwende aber immer Low() to High(), weil ich dadurch einen Code schreibe der immer funktioniert. Egal ob ich in einem halben jahr ein dynamisches Array zu einem 1 basierendem statischen Array umstelle oder nicht. Auch solche klassischen Fehler wie die Übergabe eines nicht 0-basierenden statischen Arrays an eine Procedure die einen dynamische Array als Parameter hat und dann in der Procedure mit der alten Indizierung auf das Array zugreifen, kann mir dadurch nicht passieren. (bei der Übergabe wird das Array automatisch zu einem 0-basierenden).

Aber wie gesagt, in deinem Fall hier, macht es keinen Unterschied.

[Jonas]

Naja das mit dem Kleiner machen hast du recht. Das habe ich bisher nicht gemacht.

Dennoch, ich bekomme wenn ich das Programm laufen lasse nach ca. 5 Minuten einen OutOfResources Error, was nicht an meiner Procedure, sondern ganz klar an der Funktion liegt. Denn die Procedure erstellt ja nur in dem Falle ein Fenster sobald sich wirklich ein neues Öffnet oder eins geschlossen wird, erst dann reagiert sie ja wirklich 'aktiv'. Aber auch wenn dies genau nicht der Fall ist, bekomme ich nach 5 Minuten nichts tun einen OutOfResources error.

[Muetze1]

Tja, dann ist das Problem so jetzt für uns schlecht nachvollziehbar. Grundlegend sollte meine Funktion in Ordnung sein, daher vermute ich das Problem eher an dem Programmcode von dir drumherum. Daher kann ich ohne das Programm schwer was dazu sagen. Entweder debuggst du weiter und schaust dir deinen Code (White Box Test/Black Box Test) oder du postest die Aktionen um den Aufruf der Funktion...