bringt GetLastError nach raise Exception noch etwas?

[QuickAndDirty]

Hallo ,
ich habe das eine ziemlich pauschale Execption welche die VCL intern raised wenn eine Windows Funktion fehlschlagt.

Kann ich in meinem Programm im Except Teil SyserrorMessage(GetlastError) benutzen um den genauen Fehlergrund melden zu können?

Der Try except block kapselt exakt nur diese eine VCL Methode die eben die Windows Funktion aufruft.

Ich will eben vermeiden die VCL zu modifizieren.

[jaenicke]

Solange danach keine andere Windows-Funktion aufgerufen wurde, die ebenfalls einen Fehlerstatus setzt, geht das, ja.

[himitsu]

Also kein EurekaLog und Co. verwenden, denn die machen ganz viel.

Es kommt auch auf die Exception (Einige machen noch was im Constructor),
dann noch auf die Try-Finally/Except und Prozedurebenen zwischen der Exception und dem Except.

Wie z.B. Speicherfreigaben lokaler Vriablen.


Aber: Da GetLastError nicht verwendet wird, wenn eine Exception geworfen wird, mußt du nur nach dem/den WinAPI-Aufruf(en), welche(r) GetLastError setzen könnten, dieses sofort abfragen und zwischenspeichern.

[QuickAndDirty]

Ja ich habe da so einen Cashmechanismus für Stammdaten (wir haben sehr viele stammdaten), Bewegungsdaten werden natürlich live ermittelt...
Das ganze Erfolgt in einem Timer Ereignis.

Delphi-Quellcode:

    Try
      //Timer sperren
      MyTimer.Enabled := False; //der Ruft nur killtimer aus updatetimer auf. aber hier könnte evtl Getlast error auch schon einen Wert haben....:( ok
      RefreshDatasets; //Die Stammdaten neu cachen welche in der loggtabelle Änderungen aufweisen.
      MyTimer.Enabled := True;  //<-- hier passiert der Fehler 
                                //bzw in der methode Extctrls.TTimer.UpdateTimer;
    except
      on E:Exception do
      begin
        e.message := 'Fehler 67: ' + e.Message+ 
                     #13#10' SysErrorMessage:'+SyserrorMessage(GetlastError);
        MyTimerActive := false;
        raise;
      end;
    end;

UpdateTimer ist in Delphi 7 seltenst dämlich implementiert! Weil die Fehler meldung nur auf Systemen kleiner windows 2000 sinnstiftend ist. Diese Methode möchte ich aber nicht patchen!

Delphi-Quellcode:

procedure TTimer.UpdateTimer;
begin
  KillTimer(FWindowHandle, 1);
  if (FInterval <> 0) and FEnabled and Assigned(FOnTimer) then
    if SetTimer(FWindowHandle, 1, FInterval, nil) = 0 then
      raise EOutOfResources.Create(SNoTimers);
end;

[himitsu]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117446)

<-- hier passiert der Fehler

Welcher Fehler?
Wird

Delphi-Quellcode:

EOutOfResources.Create(SNoTimers);

etwa ausgelöst?

[QuickAndDirty]

Ja genau der wird ausgelöst ("nicht genügend timer verfügbar")
Und die Fehlermeldung hat mit der Realität nichs zu tun...denn das eigentliche Problem dürfte sein das der Rechner kurz davor mehrfach eingefroren ist...und hinterher neugestartet werden musste..

Der Text ist nicht wirklich aussagekräftig auf Rechnern größer NT4.0
Deswegen will ich zusätzlich die SysErrorMessage haben!

[DeddyH]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117528)

Der text ist also nicht wirklich aussage kräftig auf Rechnern größer NT4.0

[OT] Wenn man auch so modernes Zeugs einsetzt... :twisted: (SCNR) [/OT]

[QuickAndDirty]

[OT]

Zitat:

Zitat von DeddyH (Beitrag 1117529)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117528)

Der text ist also nicht wirklich aussage kräftig auf Rechnern größer NT4.0

[OT] Wenn man auch so modernes Zeugs einsetzt... :twisted: (SCNR) [/OT]

Wenn man Timer auf Formularen spammen will, kommt man da nicht drum herum.
[/OT]

[jaenicke]

Zitat:

Zitat von QuickAndDirty (Beitrag 1117528)

Ja genau der wird ausgelöst ("nicht genügend timer verfügbar")
Und die Fehlermeldung hat mit der Realität nichs zu tun...denn das eigentliche Problem dürfte sein das der Rechner kurz davor mehrfach eingefroren ist...und hinterher neugestartet werden musste..

Doch, das ist genau das Problem. Irgendein Programm schnappt sich da zu viele Handles, und Windows 2000 hat halt nicht so viele zur Verfügung.

Das Problem ist also eher ein konzeptionelles, sei es in diesem oder einem anderen Programm...

[QuickAndDirty]

Zitat:

Zitat von jaenicke (Beitrag 1117542)

Zitat:

Zitat von QuickAndDirty (Beitrag 1117528)

Ja genau der wird ausgelöst ("nicht genügend timer verfügbar")
Und die Fehlermeldung hat mit der Realität nichs zu tun...denn das eigentliche Problem dürfte sein das der Rechner kurz davor mehrfach eingefroren ist...und hinterher neugestartet werden musste..

Doch, das ist genau das Problem. Irgendein Programm schnappt sich da zu viele Handles, und Windows 2000 hat halt nicht so viele zur Verfügung.

Das Problem ist also eher ein konzeptionelles, sei es in diesem oder einem anderen Programm...

Ja aber es hat mit der Timer-Beschränkung in den älteren Windows Versionen nichts zu tun. Deswegen ist die Fehlermeldung falsch! Und entweder bekomme ich dort gerade einfach kein Handle...was ja dann eine Problem aller Anwendnungen dieses PCs ist...bzw. einer Anwendung dieses Pcs die handles leckt.
Und das ist wohl in diesem fall auch der fall (Vermutung) oder ich schreibe z.B. wie wild in dem Programm im Arbeitsspeicher herum und kotaminiere die Hwnd variable... &c...
Auf jedenfall wäre es super sinnvoll die richtige Fehlermeldung zu bekommen, statt dieses Standardtextes

[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!