Hallo zusammen,

ich habe da ein kleines Problem mit den Threads. Dieser wird über einen Button gestartet und über den selber auch wieder beendet.
Dies klappt beim ersten mal. Wenn ich den Thread ein zweites mal starten möchte, lande ich wieder beim Beenden, also in der Else-Abteilung...

Hier der Code dazu:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TTrapo_II_Form.ReplayProc(Sender: TObject);
begin;
 if not assigned (replay)// replay = NIL <- als Test mit dem gleichen Ergebnis
  then begin;
   opendialog.Filter := 'PSM Logdaten|*.clg';
   opendialog.InitialDir := extractfilepath(application.ExeName)+'Daten\Aufzeichnungen\';
   if opendialog.Execute
    then begin;
     replay := TReplay_Thread.Create(true);
     replay.pfad := opendialog.FileName;
     Replay.Priority := tpIdle;
     Replay.FreeOnTerminate := true;
     Replay.start;
    end;
    replayBtn.ImageIndex := 7;
    replayBtn.Caption :=' Anhalten';
  end
  else begin;
    replay.Terminate;
    replayBtn.ImageIndex:=5;
  end;
end;

Der Versuch "replay.isRunning" schlägt fehl, da Replay erst danach erstellt wird.
Wie kann ich "Replay" im Else Zweig so aus dem Speicher bekommen, das ich beim nächsten klick wieder Starten kann ?

Danke schonmal.

Gruß

Torsten

assigned (replay) bringt hier absolug garnichts, da durch Replay.FreeOnTerminate:=true ab dem Replay.start; dieser Referenzzeiger als "ungültig" zu betrachten ist, weil der niemals auf nil gesetzt wird, aber die Instanz sich "irgendwann" selbst zerstört.

[edit]
Der Thread muß natürlich nicht immer aktiv sein, aber die TThread-Instanz darf sich nicht freigeben, wenn man sie von extern steuern will,
oder man muß das über eine zusätzliche Variable steuern, welche der Thread entsprechend umschreibt, bevor er sich verabschiedet.

Ich würde den Thread immer am Leben lassen, aber seine Aufgabe über ein TEvent steuern. D.h. der Thread wartet im Execute, bis das Event signalisiert wird, erfüllt seine Aufgabe und wartet dann wieder.

Es gibt reichlich Beispiele hier, wie man das macht. Einfach mal suchen.

Wie Dejan Vu schon korrekt angemerkt hat liegt der größte Fehler in der Sichtweise beim Arbeiten mit Threads.

Ein Thread ist ein Ausführungs-Kontext. Punkt - mehr nicht!

So ein Thread kann eine Aufgabe (Task) ausführen, damit der Hauptthread (aha, noch ein Thread) dadurch nicht belastet wird, denn die Aufgabe des Hauptthreads besteht in der Kommunikation mit dem Anwender.

Vergleichen kann man das mit einem Unternehmen. Da gibt es die Mitarbeiter (Threads) und die erledigen Aufgaben (Tasks). Was mich interessiert ist nicht ob ein Mitarbeiter aufhört (ich bin nicht vom Personalwesen), sondern ob die Aufgabe erledigt wurde.

Das Konstrukt aus dem Ausgangspost könnte man wie folgt darstellen:
Ich stelle einen Mitarbeiter für genau eine Aufgabe ein und wenn der diese Aufgabe erledigt hat, dann kann er sich wieder schleichen (FreeOnTerminate) So, den Erwin habe ich dafür gewonnen und der geht auch fröhlich an sein Werk. Nach einer gewissen Zeit rufe ich dann Erwin .... aber da kommt keine Antwort. Der Erwin ist einfach schon nach Hause gegangen.

In Delphi XE7 ist das jetzt (endlich aber noch nicht abschließend) integriert. Da gibt es ThreadPools (die Personalabteilung) und Tasks (Aufgaben). Man erstellt einfach nur noch Aufgaben (Tasks) und die Personalabteilung (ThreadPool) kümmert sich darum, dass genügend Mitarbeiter (Threads) vorhanden sind abhängig von den verfügbaren Ressourcen (Auslastung der CPU).