Timer stoppen

[bluesbear]

Zitat von SirThornberry:

Das ist richtig. Du kannst ja am Ende das Enabled von einer Bedingung abhängig machen
TTimer(Sender).Enabled = Timer_still_needed;

Na, wenn man schon einen Timer nimmt, dann sollte man ganz ohne Application.ProcessMessages auskommen. Sonst könnte er ja gleich eine while-Schleife nehmen. Siehe meine (viel zu langsam editierten) Posts weiter oben.

[SirThornberry]

genau, das Application ProcessMessages sorgt dort drin nur dafür das es möglich ist in einer anderen procedure das Object weg zu ziehen.
Daher am besten mit einem switch arbeiten und zusätzlich natürlich den Timer im Timer-Event abschalten falls eine Aktion mal etwas längert dauert damit sich die Timer-Events dann nicht aufstauen.

[bluesbear]

Zitat von SirThornberry:

genau, das Application ProcessMessages sorgt dort drin nur dafür das es möglich ist in einer anderen procedure das Object weg zu ziehen.
Daher am besten mit einem switch arbeiten und zusätzlich natürlich den Timer im Timer-Event abschalten falls eine Aktion mal etwas längert dauert damit sich die Timer-Events dann nicht aufstauen.

Eine Variante ohne das hatte ich oben ja schon vorgeschlagen. Worüber ich gerade grüble: Können sich Timer-Events überhaupt aufstauen? Wenn ja, wo? Im Windows Message Queue? Oder werden die einfach unterschlagen? Ich dachte bis jetzt letzteres.

[DeddyH]

Eher ersteres, Timer können sich "selbst überholen", wenn das Intervall im falschen Verhältnis zur benötigten Abarbeitungszeit steht.

[SirThornberry]

genau, sie stauhen sich in der Messagequeue. Das merkt man besonders gut wenn man mal einen Breakpoint setzt schritt für Schritt durchgeht und plötzlich wieder am Anfang der Funktion ist weil der nächste Aufruf durch Application.ProcessMessages kam.

[bluesbear]

Zitat von DeddyH:

Eher ersteres, Timer können sich "selbst überholen", wenn das Intervall im falschen Verhältnis zur benötigten Abarbeitungszeit steht.

Aber dann müsste er doch 'nachlaufen', wenn man ihn Enabled := False setzt. Das tun die Dinger nicht.
Ich glaube mich wieder erinnert zu haben: Wenn ein Timer sich "überholt" wird genau ein Event erzeugt, auch bei mehrfacher Überholung. Und das dann sofort ausgeführt, wenn der OnTimer abgearbeitet ist.
Von daher ist SirThornberry's (Apostroph weil englisch) Idee gut, denn dann wird am Ende von OnTimer der Timer neu gestartet, und es vergeht ein Timerintervall bis zum nächsten Event.

[DeddyH]

Ich habe doch gar nichts Gegenteiliges behauptet. Wenn ich weiß, dass mein Timer evtl. länger als Intervall brauchen könnte, setze ich ihn auch immer auf false, lasse ihn abarbeiten und aktiviere ihn dann wieder.

[bluesbear]

Zitat von SirThornberry:

genau, sie stauhen sich in der Messagequeue. Das merkt man besonders gut wenn man mal einen Breakpoint setzt schritt für Schritt durchgeht und plötzlich wieder am Anfang der Funktion ist weil der nächste Aufruf durch Application.ProcessMessages kam.

Ich bin schon wieder zu langsam - jetzt, wo Du es sagst: Das Application.ProcessMessages im OnTimer kann sich in der Tat böse auswirken bei Überholvorgängen, bis zum stack overflow
Das war mir noch gar nicht aufgefallen. Sollte man also besser nicht machen.

[bluesbear]

Zitat von DeddyH:

Ich habe doch gar nichts Gegenteiliges behauptet.

Ich bin ein bißchen durcheinander gekommen mit der Message-Reihenfolge hier im Thread. Ich fühle mich wie ein OnTimer Event mit einem Application.ProcessMessages drin, bei den kurzen Antwort-Intervall hier

[DeddyH]

Ja, ab 40 lässt die Reaktion rapide nach, ich kenne das

[edit] Rechtschreibung [/edit]