Thread + Timer, Einbinden von TimerThread.pas

[LTE5]

Ich denke ich habs jetzt raus.
Das while in override ExecuteTimed muss natürlich raus weil das TCustomThread.Execute; in einer Schleife ja auch immer ExecuteTimed aufruft.
Nun funktioniert auch Enabled richtig.

Zitat:

Vergiss doch einfach den Event im ExecuteTimed

Wie soll ich denn das Event vergessen. Braucht man das im eigenen Thread, also der Ableitung, im ExecuteTimed gar nicht?

Dann wird Beitrag 18 vermutlich falsch sein
http://www.delphipraxis.net/1390098-post18.html

[Fritzew]

Zitat:

Wie soll ich denn das Event vergessen. Braucht man das im eigenen Thread, also der Ableitung, im ExecuteTimed gar nicht?

Nein brauchst Du nicht, das ist ja der Witz and der Klasse.
Du machst eine Ableitung,
überschreibst ExecuteTimed und gut ist. Im alles andere kümmert sich die Thread-Klasse

[LTE5]

Zitat:

Aufgeweckt wird der Thread entweder wenn TimeOut aufgetreten ist oder wenn mit SetEvent der Event gesetzt wird (extern oder ggf. im Destructor)

Von Außen kann man den Thread leider nur aufwecken, wenn man folgende Änderungen in der Unit vornimmt

Delphi-Quellcode:

public
 property Event: TEvent read FEvent write FEvent; // Damit man Event von Außen überhaupt sieht

Und in TCustomThread.Execute

Delphi-Quellcode:

// Aus
if FEvent.WaitFor(LInterval) = TWaitResult.wrTimeout then

// wird
if FEvent.WaitFor(LInterval) in [TWaitResult.wrTimeout, TWaitResult.wrSignaled] then

Nur bin ich mir bei der letzten Zeile nicht so sicher, ob das OK ist.

Von Außen kann man dann aufrufen

Delphi-Quellcode:

TestThread.Event.SetEvent;

[Fritzew]

Delphi-Quellcode:

if FEvent.WaitFor(LInterval) in [TWaitResult.wrTimeout, TWaitResult.wrSignaled] then

Das ist Ok, aber den Event ohne Setter und Getter sichtbar machen nicht.

Lass das weg und benutze im code doch einfach das Enabled Property, da wird der Event auch ausgelöst. (Threadsafe)

[LTE5]

Wenn ich aber das Property Enabled verwende, hat das nicht denselben Zweck.

SetEvent bräuchte ich, um sofort aus dem WaitFor rauszukommen und alles weitere in ExecuteTimed auszuführen.

Enabled auf False stellen würde WaitFor für INFINITE lang im Kreis rennen lassen.

[Mavarik]

Zitat:

Zitat von LTE5 (Beitrag 1390228)

Wenn ich aber das Property Enabled verwende, hat das nicht denselben Zweck.

SetEvent bräuchte ich, um sofort aus dem WaitFor rauszukommen und alles weitere in ExecuteTimed auszuführen.

Enabled auf False stellen würde WaitFor für INFINITE lang im Kreis rennen lassen.

Sorry, aber langsam wird es anstrengend... Versuch doch einfach aufgrund meines alten postings zu verstehen, wie es funktioniert und setzt dann einfach das Timeout nicht auf Infinite sondern auf den Wert den Du brauchst... Fertig.

[LTE5]

Zum Glück seid ihr keine Lehrer. Denn sonst hättet ihr mit circa 90% solcher Idioten zu tun wie ich :thumb:

[Mavarik]

Zitat:

Zitat von LTE5 (Beitrag 1390232)

Zum Glück seid ihr keine Lehrer. Denn sonst hättet ihr mit circa 90% solcher Idioten zu tun wie ich :thumb:

Nö, wenn ich Lehrer wäre hätte ich es Dir direkt richtig und so beigebracht, dass Du es verstehst...

[LTE5]

Eine Frage habe ich noch zu diesem ExecuteTimes.

In ExecuteTimed ist eine while-Schleife. Was aber, wenn ich eine Aufgabe habe die von Anfang bis Ende nur einmal durchlaufen soll und wo ich keine Schleife benötige?
Würde man in diesem Falle den Thread dafür erzeugen und sofort terminieren?

[Mavarik]

Zitat:

Zitat von LTE5 (Beitrag 1390236)

Eine Frage habe ich noch zu diesem ExecuteTimes.

In ExecuteTimed ist eine while-Schleife. Was aber, wenn ich eine Aufgabe habe die von Anfang bis Ende nur einmal durchlaufen soll und wo ich keine Schleife benötige?
Würde man in diesem Falle den Thread dafür erzeugen und sofort terminieren?

Poste einfach mal Deinen Source..