Fehlermeldung "Nicht genügend Timer verfügbar"

[Sinspin]

TTimer ist aus meiner Sicht gruselig implementiert. Erfüllt aber sicher seinen Zweck für den er gedacht ist.

Wenn ich deinen Fall richtig verstehe, also eine verzögerte Aktion nach einer Scrollaction auszuführen, ist villeicht ein ganz anderer Ansatz sinnvoller.
Am Ende brauchst du ja nur ein Event für deine Aktion, aber sicher nicht für jedes ScollEvent, sondern nur einmal nach dem letzten ScrollEvent.

[himitsu]

Nunja, es gibt/gab keine Möglichkeit rauszufinden welcher Timer vorhanden/aktiviert ist.

Drum nutzen die einfach immer blind ID 0, mit jeweils einem eigenem Fenster.
Die andere Variante wäre ja z.B. im Owner-Fenster den Timer zu nutzen, aber wenn du mehrere TTimer und/oder sonstwas hast, dann müssten irgendwie die IDs verteilt werden.

Und im FMX dann nochmal verschachtelt, oder gar ganz anders, für andere Platformen.




Es gibt noch eine/mehrere andere uralte MultiMediaTimer-APIs, welche z.B. mit einem Thread arbeiten, anstatt mit Window-Messages.
z.B. CreateTimerQueueTimer

[Delphi.Narium]

Ein weiteres Problom könnte sein, dass der Timer bereits wieder ausgelöst wird, während die Timerroutine noch nicht vollständig abgearbeitet ist.

Seit dem ich bei Timerroutinen zuerst den Timer ausschalte und am Ende wieder einschalte, hab' ich das Problem nicht mehr gehabt.

Delphi-Quellcode:

procedure Tform1.tmTimer(Sender: TObject);
begin
  tm.Enabled := false;
  // tu mal was
  tm.Enabled := true;
end;

[Uwe Raabe]

Zitat von Delphi.Narium:

Ein weiteres Problom könnte sein, dass der Timer bereits wieder ausgelöst wird, während die Timerroutine noch nicht vollständig abgearbeitet ist.

Ich glaube, das ist technisch nicht möglich, da weitere Timer-Events erst beim nächsten Abarbeiten der Message Queue auftauchen würden. Es kann also schon sein, dass nach Abarbeiten des Timer-Events bereits ein weiterer Event ansteht, aber eben erst nach dem Beenden des Events. Die Timer-Messages werden ja nur nach Anfrage erzeugt. Solange also niemand (auch nicht indirekt) innerhalb des Event-Codes ein PeekMessages aufruft, sollte auch keine neue Timer-Message in der Queue landen.

Das ist ja auch einer der Gründe, warum man kein Application.ProcessMessages aufrufen soll, denn dann könnte tatsächlich der Eventhandler rekursiv aufgerufen werden. Dann nutzt aber das Disablen des Timers auch nicht wirklich viel, da das ein Re-Entering nicht 100%ifg verhindern kann - es könnten ja schon weitere Timer-Messges in der Queue sein. Das Disable/Enable erzeugt aber unnötig weitere KillTimer/SetTimer Aufrufe und belastet das System eigentlich mehr als es hilft.

[Delphi.Narium]

Das mag theoretisch alles so stimmen, meine praktische Erfahrung mit Delphi 7 ist halt, dass das Problem bei mir seit gefühlt 10 Jahren nicht mehr auftritt, seitdem ich die Timer zuerst auf Enabled Disabled setze, dann die Timerlogik abarbeiten lasse und dann den Timer wieder auf Enabled setze.

Und nein, schön find' ich das nicht, aber besser als ab und an 'ne Exception wegen Timerfehlern

[haentschman]

Moin...

Zitat:

Seit dem ich bei Timerroutinen zuerst den Timer ausschalte und am Ende wieder einschalte, hab' ich das Problem nicht mehr gehabt.

...hatte ich auch noch nie. Wegen schon immer:

Delphi-Quellcode:

FLoadTimer.OnTimer := DoOnLoadTimer;
...
procedure TfoBaseRibbon.DoOnLoadTimer(Sender: TObject);
begin
  LoadTimer;
end;
...
procedure TfoReceipt.DoOnReceiptAfterScroll(Sender: TObject; ReceiptID: Integer; ReceiptDate: TDateTime; ReceiptNumber: string); // kommt von Dataset.AfterScroll
begin
  if (not FInCreation) and (not FIsShowing) then
  begin
    FLoadTimer.Enabled := False;
    FLoadTimer.Enabled := True;
  end;
end;
...
procedure TfoAddress.LoadTimer;
begin
  inherited;
  FLoadTimer.Enabled := False;

Zitat:

Am Ende brauchst du ja nur ein Event für deine Aktion, aber sicher nicht für jedes ScollEvent, sondern nur einmal nach dem letzten ScrollEvent.

Genau.

Zitat:

ist villeicht ein ganz anderer Ansatz sinnvoller.

...Idee?

[jaenicke]

Zitat von haentschman:

Zitat:

ist villeicht ein ganz anderer Ansatz sinnvoller.

...Idee?

Ich verwende dafür wie auch schon genannt wurde Threads. Dafür kannst du dir einmal eine passende Klasse bauen, die auch wirklich sehr einfach ist, und dann immer nutzen.

Das mache ich dann so:
Ich verwende ein TEvent zur Signalisierung, dass ein Scrollevent aufgetreten ist. Daraufhin setzt der Thread das Event zurück und wartet erneut auf das Event mit der vorgegebenen Zeit als Timeout (Event.WaitFor). Tritt nun in der Zwischenzeit das Event erneut auf (Ergebnis wrSignaled), wartet der Thread erneut. Ist das Ergebnis der Warteoperation der Timeout (Ergebnis wrTimeOut), wird ein OnExecute-Ereignis gefeuert, so dass die Verarbeitung starten kann.

So stellst du sicher, dass nach dem letzten Scrollereignis genau die gewünschte Zeit vergeht.

[Uwe Raabe]

Nur so 'ne

Zitat von haentschman:

...Idee?

Lass den Timer mit einer höheren Frequenz (z.B. 100ms) durchlaufen. Im AfterScroll merkst du dir den aktuellen TimeStamp mit TStopWatch.StartNew . Im Timer-Event prüfst du dann mit TStopWatch.ElapsedMilliseconds , ob eine ausreichend lange Zeit nach dem letzten Scroll vergangen ist und falls ja reagierst du entsprechend.

Vorteil: Der Timer wird nur einmal erzeugt und freigegeben.