bringt GetLastError nach raise Exception noch etwas?

[himitsu]

Jupp, ich würde auch eher mal versuchen hier mehr Handle freizubekommen.



Ansonsten: Da dieses die Einzige Exception in MyTimer.Enabled ist, mußt du einfach für MyTimer.Enabled und für RefreshDatasets jeweils eine eigene Exceptionbehandlung eingauen.

[jaenicke]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117550)

Ja aber es hat mit der Timer-Beschränkung in den älteren Windows Versionen nichts zu tun.

Solche Beschränkungen gibt es in allen Windowsversionen. Du kannst auch "nur" 10.000 GDI-Handles oder so erstellen.

Mehr als eine Handvoll Timer braucht man ja ohnehin nie, aber diese teilen sich die Ressourcen mit anderen Elementen. Vielleicht sind zu viele andere Objekte erstellt worden oder so.

[QuickAndDirty]

Wie gesagt das ist der Rechner fast eingefroren und dabei kam diese meldung.
Ich sehe diese Meldung eher als Folge und das mehrfachen einfrieren des rechners als ursache. Die (ein Kunde) mussten danach den Rechner neustarten.

Zumindest haben Tausende von Kunden dieses Problem nicht.

Habe nich nicht rausbekommen was da genau lief...die wollen von mir ne Erklärung, haben aber keine Zeit für mich...und ich wollte diesmal auf die Glaskugel verzichten.

Werde die Fehlerbehandlung umbauen und die TimerEnableTrue einzeln und mit SysErrorMessage(GetLastError) behandeln.

Danke alle.

[jaenicke]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117597)

Wie gesagt das ist der Rechner fast eingefroren und dabei kam diese meldung.

Das ist logisch, dass da der Rechner einfriert. Das bestätigt eher, dass die Handles das Problem sind. :lol:

Wenn das System keine Handles mehr belegen kann, ist halt nicht mehr viel möglich...

Wie viele von einem Prozess belegt sind siehst du in Tools wie dem Process Explorer. Wenn dort bei einem der laufenden Prozesse sehr hohe Zahlen (z.B. mehrere tausend) stehen, gibt es mit dem Prozess ein Problem...

Anhang 34907

[Luckie]

Über wie viele Timer reden wir denn?

[himitsu]

Und jeder TTimer verbraucht auch zusätzlich noch ein unsichtbares Fenster (also jeweils ein GDI-Handle und dazu ein Timer)

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1117656)

Und jeder TTimer verbraucht auch zusätzlich noch ein unsichtbares Fenster (also jeweils ein GDI-Handle und dazu ein Timer)

Das Fensterhandle meinte ich auch, denn ich glaube die Timer zählen als Kernelobjekte. Und die haben keine so enge Beschränkung.

[QuickAndDirty]

Zitat:

Zitat von Luckie (Beitrag 1117652)

Über wie viele Timer reden wir denn?

Wir haben in unserer Anwendung sicher mehr als 10 aber es laufen niemals mehr als 2 und auch nur wenn du bestimmte Optionen zu schaltest.
Also es liegt sicher nicht an der Anzahl der Timer außer MS hat dafür eine Gruppenrichtlinie......

Irgendwas ist dort schiefgegangen und unser Programm hat sich darauf gemeldet...also sollen wir das mal heraus finden...ist ja auch ok. So kann ich den Code Eindeutiger machen und wenn es an uns lag, 'nen Fehler entfernen bevor er bei diesem oder anderen Kunden echten schaden anrichtet und wenn es nicht an uns lag ist es eine Dienstleistung außerhalb des Wartungsvertrages ...schließlich warten wir nur das Auto und nicht die Straße auf der es fährt....

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1117649)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117597)

Wie gesagt das ist der Rechner fast eingefroren und dabei kam diese meldung.

Das ist logisch, dass da der Rechner einfriert. Das bestätigt eher, dass die Handles das Problem sind. :lol:

Wenn das System keine Handles mehr belegen kann, ist halt nicht mehr viel möglich...

Wie viele von einem Prozess belegt sind siehst du in Tools wie dem Process Explorer. Wenn dort bei einem der laufenden Prozesse sehr hohe Zahlen (z.B. mehrere tausend) stehen, gibt es mit dem Prozess ein Problem...

Anhang 34907

Ich weiß leider scheint weder der Admin noch die Sachbearbeiterin mal nachgeschaut zu haben!
Eine ordentliche Fehler Meldung hätte den Admin evtl. zu dem richtigen screenshot bewegt!