Fehlermeldung "Nicht genügend Timer verfügbar"

[haentschman]

Hallöle...

In den letzten 2 Wochen hatte ich folgende Meldung 2x:

Zitat:

exception class : EOutOfResources
exception message : Nicht genügend Timer verfügbar.

main thread ($3e44):
00b77240 +064 SEAM.exe Vcl.ExtCtrls 3215 +4 TTimer.UpdateTimer
00b77274 +008 SEAM.exe Vcl.ExtCtrls 3223 +3 TTimer.SetEnabled
03a6d358 +058 SEAM.exe Form.Receipt 947 +4 TfoReceipt.DoOnReceiptAfterScroll

Ich der Anwendung habe ich nur 2 Timer für die Verzögerung beim Scroll für das Laden der Detaildaten.

...weil ich das erste Mal das ignoriert hatte, weiß ich nicht, ob es der selbe Arbeitsplatz war.

PS: die Tante ist mit diesem Fehler und Delphi/VLC dürftig. Da war nur von Skins die Rede.
PS: Die Timer sind schon seit Jahren drin...problemlos.

Was kann ich noch kontrollieren?

Danke

[Sinspin]

Hey, ich erinnere mich sowas vor Jahren mal gesehen zu haben. Da hatte ich versucht Timer mehrmals pro Sekunde an und aus zu schalten.
Es scheint so zu sein dass jedesmal intern ein neuer Timer erzeugt wird. Die alten aber nicht sofort freigegeben werden.
Damals konnte man damit den Rechner zu einem Freeze/Bluescreen bewegen.

Ich verwende so gut wie überhaupt keine TTimer mehr. Sondern eigene Threads die via QueryPerformanceCounter arbeiten.

[DeddyH]

http://www.delphigroups.info/2/35/440863.html

Zitat:

If you have a look in the VCL source you will see that this message is generated whenever SetTimer fails - regardless of the reason for that failure, which might have nothing to do with insufficient timers being available. Bear in mind that TTimer component calls SetTimer a LOT - everytime enabled is changed or the interval is altered. I recall a case once when this error was being generated because the FWindowHandle field of TTimer was being corrupted. This caused SetTimer to fail (InvalidHandle) but the error message was 'Not enough timers available' - which was very misleading in this case.

[haentschman]

Danke...

Zitat:

Da hatte ich versucht Timer mehrmals pro Sekunde an und aus zu schalten.
Es scheint so zu sein dass jedesmal intern ein neuer Timer erzeugt wird.

...again what learned.

Zitat:

error message was 'Not enough timers available' - which was very misleading in this case

+ 1

Fazit: Kannst machen nix, mußt du gucken zu...

Zitat:

Da hatte ich versucht Timer mehrmals pro Sekunde an und aus zu schalten.

...das passiert ja mit dem Scrollen.
...wieder Arbeit...Umbau auf Thread.

[himitsu]

SetTimer kennt nicht nur OutOfRessources ... tja, wenn man GetLastError/SysErrorMessage vergisst und nicht den "richtigen" Fehler anzeigt.

[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