HttpClient wirft Fehler 12019 wenn zweitesmal aufgerufen (gelöst)

[Kishmet]

Hallo zusammen,

ich versuche gerade Schaltflächen zu designen die auf die zugrundeliegende IP "Pingen" und den Status der URL abfragen, speziell in hinblick auf die Userauthentification. Leider scheitere ich gerade daran und hoffe das mir hier jemand helfen kann.

Ich erzeuge mit FMX einen Frame (Dieser ist die Basis für die Schaltfläche) der mit etwas Daten gefüllt ist. Eines der Elemente ist eine TPaintbox, in der ich farblich den Status darstellen möchte.

Im OnPaintevent der Paintbox ist folgendes hinterlegt (Der Code wurde entsprechend angepasst in Reaktion auf Himitsus Post):

Delphi-Quellcode:

procedure TPCConnectFrame.RefreshStateIcon;
var
  Checkup_ready     : Boolean;
  response          : IHTTPResponse;
  Response_msg      : String;
  Item              : TmyItem; //enthält nutzername, passwort, http addresse (als property mit getter da abhängig von Gerätetyp)
begin
  Checkup_ready := FALSE;
  //einige Arbeiten für die "initialisierung" der Funktionskomponenten
  Item := ÜbergebendeKlasse.Items[0];
  ...
  //Weiterer Code zur gestaltung der Painbox und unterscheidungen
  ...
  TThread.CreateAnonymousThread(
      procedure
      var
        Netclient_Checker : TNetHTTPClient;
      begin
        //Das create (natürlich) immer vor das Try! - war mir beim ersten Übertrag hier ins Forum verrutscht
        Netclient_Checker := TNetHTTPClient.Create(nil); //Hier lag der erste Fehler! Ich hatte ein Self für das create verwendet, aber wie himitsu richtig gesehen hat ist dies so nicht richtig!
        try
          Netclient_Checker.CredentialsStorage.AddCredential(TCredentialsStorage.TCredential.Create(TAuthTargetType.Server, '', '', Item.Username, Item.Password));
          try
            ...
            response := Netclient_Checker.get(Item.http_Address);  
            //Weiterer Code
            ...
          except
            ...
            //Fehlerbehandlung für den TNetHTTPClient im falle einer exception. bspw. wenn die Kamera nicht erreichbar ist und ein timeout entsteht. 
            ...
          end;
        finally
          Checkup_ready := TRUE;
          Netclient_Checker.Free; //Ebenfalls mit FreeAndNil versucht weil ich ein unsauberes Schließen im Verdacht hatte
        end;
      end).Start;

    while not Checkup_ready do
    begin
      Application.ProcessMessages;
    end;

    //Weiterer Code
end;

Wenn ich das Element, auf dem das Verknüpft ist nun das erste mal erzeuge passt auch alles. Die gesamte Schaltfläche wird korrekt initialisiert und der Code läuft entsprechend durch.

Jetzt zu meinen beiden Problemen:

1. Ich würde erwarten, dass ich wenn ich während der Ausführung irgendwo anders hinklicke dieser click auch ausgeführt wird, da ich ja während der thread läuft in der Schleife mit Application.processmessages festsitze. leider klappt das nicht und mir leuchtet gerade nicht ein warum?
2. Wenn ich den Tab wechsel und zurück komme, klappt der Code oben plötzlich nichtmehr sondern wirft eine Fehlermeldung bei der zeile
   Code:

   response := Netclient_Checker.get(Item.http_Address);

   
   

   Zitat:

   Im Projekt MeineApp.exe ist eine Exception der Klasse ENetHTTPException mit der Meldung 'Fehler beim Abrufen der Header: (12019) Der Status des Handles entspricht nicht dem angeforderten Vorgang' aufgetreten.

Ich bin mir recht sicher das der Fehler ein Threadingproblem ist, da ich wenn ich es durchdbugge keine Probleme habe, ebenfalls keine Probleme habe ich, wenn ich den anonymen Thread weglasse. Außerdem wird die Schaltfläche immer wenn ich wieder auf den Tab zugreife gelöscht und komplett neu initialisiert. Es sollte sich also immer um einen "Clean" start handeln.

Ist für einen der alten Hasen hier ersichtlich was ich falsch mache?

[himitsu]

Warum hörst du nicht auf die Warnungen des Compilers?

Delphi-Quellcode:

        try
          Netclient_Checker := TNetHTTPClient.Create(self);
          ...
        finally
          Checkup_ready := TRUE;
          Netclient_Checker.Free; //Ebenfalls mit FreeAndNil versucht weil ich ein unsauberes Schließen im Verdacht hatt
        end;

Hier sollte er meckern, dass diese Variable nicht initialisiert sei, was so auch richtig ist, denn wenn es im Create knallt, dann bekommt Free eine "zufällige" Variable.

Also ja, dein Verdacht könnte schon stimmen, nur ist das Free/FreeAndNil nicht der Fehler, sondern alles davor.
Selbst wenn es erst im Free und nicht schon im Create knallt, dann nur, weil vorher schon etwas falsch war.

Das Create gehört vor das Try. (oder notfalls muß es vorher zumindestens initialisiert werden)

Delphi-Quellcode:

obj := TIrgendwas.Create;
try
  ...
finally
  obj.Free;
end;

Delphi-Quellcode:

obj := nil;
try
  ...
  obj := TIrgendwas.Create;
  ...
finally
  obj.Free; // im Free ist ein if-Assigned integriert
end;

Und dann greifst du auch noch multithreaded auf die nicht-threadsafe VCL zu.

Das Self gehört hier niemals in einen Thread.
Create des TComponent registriert sich bei seinem Owner (schreibt dort also aus einem Thread in eine Komponenten-Liste) und beim Free nochmal, um sich aus dieser Liste zu löschen.
-> Netclient_Checker := TNetHTTPClient.Create(nil);
Und solche Try-Except, mit "schwachsinniger" Fehlerbehandlung, gehören verboten.
Warum wird die eigentliche Exception.Message grob fahrlässig vernichtet?

Zitat:

Response_msg := Translate('IP nicht erreichbar');

Was wäre, wenn die IP erreichbar ist, aber es einen anderen Fehler gab?

[Kishmet]

Ah... sorry. Das Create ist beim Übertrag hier ins Forum verrutscht. Das steht selbstverständlich vor dem try...

Aber das Self ... verdammt. klar macht sinn. Probier ich eben aus!

[Kishmet]

Japp das Self war es. Ein Satz frischer Augen wirkt da wirklich Wunder. Vielen Dank für die schnelle Hilfe!

Bleibt nur noch mein Problem die Software währenddessen reaktiv zu halten. Mir ist klar das die Version von Oben nicht der Burner ist, aber funktionieren sollte sie doch oder?

[Kishmet]

Guten Morgen Himitsu (und natürlich auch guten Morgen an alle anderen die dies hier lesen),

So wieder (halbwegs) frisch ans Werk.

Zitat:

Und solche Try-Except, mit "schwachsinniger" Fehlerbehandlung, gehören verboten.
Warum wird die eigentliche Exception.Message grob fahrlässig vernichtet?

Du hast recht ich hätte den Code besser reduzieren sollen War gestern ein langer Tag und ich wollte zumindest die Fehlermeldung noch los werden bevor ich mich anderen Dingen widme, leider ist mir dabei die Qualität des Codes unter Räder geraten. Sollte natürlich nicht passieren! Ich habe den Code oben nun (hoffentlich) etwas besser gestaltet. Zwar immernoch ohne den ganzen Code der dort eigentlich steht, aber mit Kommentaren die dies deutlich machen. Außerdem habe ich gleich die Fehlerkorrektur mit dem Self eingefügt und kenntlich gemacht.

Ich werde mich jetzt der reaktivität meiner Software widmen. Denn diese macht mich immernoch stuzig, auch wenn ich es mir heute noch nicht angesehen habe, vielleicht fällt es mir ja aber auf. Denn in meinem Verständnis sollte auch diese quick und dirty Variante die Reaktivität erhalten können. Falls jemand aber direkt etwas entdeckt, würde ich mich immernoch über eine Idee freuen, weshalb bspw. onMouseClick events nicht behandelt werden, welche ich auf der MainForm ausführe.


---


hab es herausgefunden. Liegt gar nicht an dem Code, sondern an einer Zeichenroutine von dem Element auf das ich später male. Die ist ziemlich langsam und blockiert in dieser Zeit die Software. Werde ich wohl auch neu machen müssen. Vielen Dank fürs Lesen!