Zitat von himitsu:

Wie kann ich also auf das Ende eines Thread reagieren?
Egal ob über TThread oder direkt über die WinAPI erstellt.

Wäre das im konkreten Fall mit Hilfe eines Eventhandlers vielleicht wie folgt zu realisieren, wobei das hier nur als Grundgerüst konzipiert ist, da ich die Einzelheiten des speziellen Projekts nicht kenne ?:

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMySpecialthread = class(TThread)
  Begin
   {...}
  protected
      procedure Execute; override;
   {...}    
  end;
  
Var
  EventHandle: THandle;
  ThreadHandle: THandle;
  MySpecialthread: TMySpecialthread;
  
procedure ToDoAfterMySpecialThreadHasFinished; stdcall;
Var ObjRtn: Cardinal;
begin
  ObjRtn := WaitForSingleObject(EventHandle, INFINITE);
  MySpecialThread.Terminate;
  Showmessage('MySpecialThread is Ready'); // eben nur als Beispiel
  { ..  DoToListe abarbeiten,
    was nach Ende des MySpecialThread zu erledigen ist ... }
  ExitThread(0);
end;

procedure MySpecialthread.Execute;
begin
   {... do it  .....}
  SetEvent(EventHandle);
end;
  
procedure TForm1.FormCreate(Sender: TObject);
var
  ThreadID: Cardinal;
begin
  EventHandle := CreateEvent(Nil, True, False, 'MySpecialThreadEvent');
  ThreadHandle := CreateThread(nil, 0, @ToDoAfterMySpecialThreadHasFinished, nil, 0, ThreadId);
  MySpecialThread:=TMySpecialThread.create(false);
  MySpecialThread.FreeOnTerminate:=false; // oder nach Bedarf true
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  Button1.Enabled:=false;
  MySpecialThread.Resume;
end;

Nunja, ich bin dabei meine Codes aufzuräumen und unter Anderem wird auch ein abstraktes Logging-System mit integriert.
(es hat selber keine Logfunktion, sondern dient nur als Schnittstelle für gewisse Grundfunktionen, um dort später irgendein Loggsystem, wie z.B. Eurekalog oder sonstewas, dort anhängen zu können)

Nun gibt es da auch folgene Methode, welche man auf unterschiedliche Weise nutzen kann, wie z.B.:

zusammenfalten · markieren

Delphi-Quellcode:

begin
  HLog.EnterMethod('Name der Prozedur'); // eventuell auch ohne Name HLog.EnterMethod;
  ...
  HLog.ExitMethod;
end;

begin
  HLog.EnterMethod('Prozedur');
  ...
  HLog.ExitMethod(Result); // oder man loggt auch noch das Result mit
end;

begin
  HLog.EnterMethod('Prozedur');
  ...
end; // HLog.ExitMethod wird automatisch aufgerufen (über ein lokales Interface)

var M: HLog.IMethod;
begin
  M := HLog.EnterMethod('Prozedur');
  ...
  M.ExitMethod(Result);
end;

Das "Event" wird allerdings erst richtig abgeschlossen, wenn die Prozedur richtig abgeschlossen wurde (über das Interface), womit auch Folgendes keine Probleme bereitet.

markieren

Delphi-Quellcode:

begin
  HLog.EnterMethod('Name der Prozedur'); // eventuell auch ohne Name HLog.EnterMethod;
  ...
  HLog.ExitMethod;
  ...
  HLog.ExitMethod(Result); // hier wird Result nur zwischengespeichert
  ...
end; // hier wird das Result erst geloggt

Bei den ersten Varianten, wo nicht explizit über das IMethod-Interface gegangen wird
und vorallem bei Multithreadanwendungen gibt es keinen physischen Zusammenhang, zwischen den einzelnen Aufrufen.
OK, jetzt könnte man zwar über die ThreadID ganz billig im ExitMethod das IMethod des aktuellen Threads raussuchen, aber davon muß es nicht nur Eines geben ... Stichwort rekursive Aufrufe.

Ich find ja die "globalen" Methoden am handlichsten, aber da fehlt eben die direkte Zusammengehörigkeit.
Weswegen es mit eigentlich am schönsten gefallen würde, das globale ExitMethod behalten zu können.

Gut, ich könnte auch eine Liste führen (als threadvar) und dann statt auf ein treadvar-ResultSave direkt auf das letzte IMethod verweisen, aber über eine globale IMethod-Variable könnte man die Erstellungs/Freigabe-Reihenfolge von verschachtelt erstellten IMethods eines Threads durcheinanderbringen.



Ist halt alles nicht so einfach.
Aber es soll auch was Ordentliches werden, womit ich dann die nächsten Jahre gut leben kann, wenn ich es bei mir überall als Basissystem einsetze.