Sorry, Ownobjects ist natürlich auf True. Hatte mich vertippt.

Guten Morgen,

neuer Tag, neues Glück.

Da mein ursprünglicher Fehler immer noch existiert, steige ich an dieser Stelle noch mal ein.

Wie bereits gesagt, wird eine Exception ausgelößt, wenn mein Thread mit dem TCP-Client (TWSocket von ICS) beendet wird bzw. beendet ist, und ich anschließen der Mainform den Focus geben, z.B. durch anklicken.
Was dann im Detail passiert kann ich schwer sagen. Aber ich nehme mal an, dass Windows sicherlich eine Window-Message schickt, deren Verarbeitung dann, aus welchen Gründen auch immer, fehlschlägt.

In meinem Programm fange ich im Grunde keinerlei Messages ab, bis auf eine einzige, die mein Thread an die Mainunit schickt wenn er sich beendet, aber die habe ich erst später hinzugefügt. Der Fehler war schon vorher da.
Leider weiß ich mir nicht zu helfen.

Wenn ich den Thread nicht erzeuge, und dem zur Folge auch nicht beende, tritt natürlich kein Problem auf.

Zu der Exception springt mir die der Debugger der IDE an folgende Stelle:

zusammenfalten · markieren

Delphi-Quellcode:

{ Standard window procedure }
function StdWndProc(Window: HWND; Message: UINT; WParam: WPARAM; LParam: WPARAM): LRESULT; stdcall;
{$IF Defined(CPUX86)}
{ In    ECX = Address of method pointer }
{ Out   EAX = Result }
asm
        XOR EAX,EAX
        PUSH EAX
        PUSH LParam
        PUSH WParam
        PUSH Message
        MOV EDX,ESP
        MOV EAX,[ECX].Longint[4]
        CALL [ECX].Pointer
        ADD ESP,12 //<- Genau hier hin.
        POP EAX
end;

Ich habe mal eine Screenshot von der IDE an dieser Stelle gemacht und angehängt. Vielleicht hat ja irgendjemand noch eine Idee, was ich machen könnte um dem Fehler auf die Spur zu kommen.

Meinen Thread häng ich auch noch mal dran, möglicherweise liegt der Fehler ja da drin.

Die Fehlerstelle ist hier eine Zeile vorher, denn leider zeigt der Debugger die Position der Rücksprungadresse an.

Der Fehler ist also in dem CALL aufgetreten, bzw. in der aufgerufenen Methode.

Zitat:

Aber ich nehme mal an, dass Windows sicherlich eine Window-Message schickt, deren Verarbeitung dann, aus welchen Gründen auch immer, fehlschlägt.

Dem würde ich mal zustimmen.

In welchem Thread-Kontext liegt das denn? (würde zwar MainThread vermuten, aber kann nicht schaden mal nachzusehn -> Thread-Status)

Hier ist der Thread-Status.
Ich muß zugeben, dass mein Wissen für die Beurteilung ob das nun der MainThread ist, nicht ausreicht.
Was ich aber sehe, dass er wohl auf eine Adresse zeigt $00000000, die wohl nicht der MainThread sein dürfte. Sondern wohl eher mein TCP-Thread, der ja nicht mehr existiert.

Da stellt sich mir gleich mal die Frage, wer schickt eine Fensterbotschaft an meinen (nicht mehr existierenden) Thread? Und das erste was mir dazu einfällt wäre ICS TWSocket, welches mit einen unsichtbaren Fenster im Hintergrund arbeitet (hab ich gelesen).
Das TWSocket ist aber mit Free entfernt...hm...ich dreh mich im Kreis und mir wird schwindelig

Hier mal der Screenshot vom Thread-Status:

Hallo Captnemo,

vielleicht gibt es einen Konflikt beim Empfangen von Messages? Wenn die Messagenummer für ICS nicht explizit auf einen Startwert gesetzt wird, benutzt ICS als erste Nummer WM_USER + 1 . Ich bin mir zwar nicht sicher, ob das zu einem Problem führen kann, aber den ICS-Messages einen Startwert zu geben, kann ja nicht schaden.
Um den Startwert zu setzen, benutze die Variable GWndHandlerMsgLow in der Unit OverbyteIcsWndControl , bevor du deine erste ICS-Komponente erzeugst.

Grüße
Thomas

Danke Thomas, das werde ich berücksichtigen.

Aber ich glaube ich bin dem Fehler auf die Spur gekommen.
Ich habe mal alle Objecte die ich im Create erzeuge auskommentiert, und dann läuft mein Thread, läßt sich beende und alle ist Okay.

Dann habe ich die schrittweise wieder eingebaut, und siehe da, als einen Timer wieder aufgenommen habe, tritt der Fehler wieder aus.
Ohne jetzt noch alle anderen Objecte zu testen (was ich aber noch mache) würde ich dann vielleicht hier den Fehler erst mal suchen.

Also im Thread.Create erzeuge ich den timer:
FUpdateTimer:=TTimer.Create(Nil); und im meiner Execute sieht's so aus:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TTCPThread.Execute;
begin
  Try
    FUpdateTimer.Interval:=60000;
    Synchronize(
      Procedure
      begin
        frm_main.Writelog('Init TCP-Connection ('+FBindIP+'@'+IntToStr(FBindPort)+')>('+FHost+'@'+IntToStr(FPort)+')');
      end
    );
    //FTCPClient.Connect;


    while not Terminated do begin
      sleep(100);
      self.Terminate;
      if Terminated then
      begin
// FUpdateTimer.Enabled:=False;
        break;
      end;
    end;
  finally
    Synchronize(
      Procedure
      begin
        frm_main.ReleasePort(FBindPort);
      end
    );
    FUpdateTimer.Free;
    Synchronize(
      Procedure
      begin
        frm_main.Writelog('Thread beenden');
      end
    );
  end;
end;

Was ist denn daran falsch? Ich erzeuge ihn....mach aber nix damit...und gebe ihn wieder frei.

Nachdem ein Thread beendet wurde, wird dessen MessageQueue gelöscht (falls er Eine hat), kurz davor die verknüpften Windows (vermute ich mal) und man kann an ihn dann auch keine Message mehr senden. (eigentlich)

Falls meine "Vermutung" nicht stimmt, dann würden die Windows ja in der Luft hängen, da ihre Messages immer nur im verknüpften Thread abgearbeitet werden. (Dem, wo das Control erstellt wurde)


Die MessageQueue eines Threads wird beim ersten Zugriff generiert, erstes PostThreadMessage an den Thread,
oder beim Erstellen eines Window in diesem Thread.


[add]

Zitat:

FUpdateTimer.Free;

Der Timer wurde im Hauptthrad erstellt (zumindestens da, wo TTCPThread.Create ausgeführt wurde).
Damit gehört er zur nicht-threadsicheren VCL des Hauptthreads und gehört auch nur dort zerstört (Synchronize).

Auch das Enabled gehört nicht in den Thread.

Außer du erstellst den Timer im Thread und mußt deinem Thread natürlich auch eine Message-Verarbeitung spendieren, denn ohne werden die Messages des Timers dann nie verarbeitet.



[add2]

Zitat:

markieren

Delphi-Quellcode:

      self.Terminate;
      if Terminated then
      begin
        break;
      end;

Ergibt das nicht einfach nur ein Exit; ?

Hab grad den Test umgekehrt gemacht. Nur TTimer weglassen, schon läuft mein Thread ohne Fehler und Probleme.

Nur was jetzt? TTimer im TThread...müßte doch gehen.

Zitat von himitsu:

Zitat:

markieren

Delphi-Quellcode:

      self.Terminate;
      if Terminated then
      begin
        break;
      end;

Ergibt das nicht einfach nur ein Exit; ?

Meines Wissens wir bei einem Exit die Procedure/Function verlassen, während ein Break nur die Schleife (for, while, Loop) verläßt.

Hilfeauszug:

Exit:

Zitat:

Beendet die aktuelle Prozedur.

In Delphi entzieht die Prozedur Exit der aktuellen Prozedur sofort die Steuerung. Wenn die aktuelle Prozedur das Hauptprogramm ist, bewirkt Exit die Beendigung des Programms.

Exit veranlasst die aufrufende Prozedur, mit der Anweisung nach dem Punkt fortzufahren, an dem die Prozedur aufgerufen wurde.

Anmerkung: Exit entzieht der aktuellen Prozedur die Steuerung, nicht nur dem aktuellen Block. Aber Exit verletzt den Steuerungsfluss nicht, der durch ein try..finally-Konstrukt vorgeschrieben ist; wenn Exit in der try-Klausel aufgerufen wird, wird die finally-Klausel dennoch ausgeführt.

Break:

Zitat:

Beendet eine for-, while- oder repeat-Anweisung vorzeitig.

In Delphi bewirkt Break, dass eine for, while oder repeat-Schleife verlassen und die Ausführung mit der nächsten Anweisung fortgesetzt wird.

Wird Break außerhalb einer for-, while- oder repeat-Anweisung aufgerufen, gibt der Compiler eine Fehlermeldung aus.

Anmerkung: Break wirkt sich nicht auf die Ablaufsteuerung von try..finally-Konstrukten aus. Wenn Sie Break in der try-Klausel aufrufen, wird die Ausführung in der finally-Klausel fortgesetzt.

Du hast zwar in sofern Recht, als dann der finally-Abschnitt ausgeführt wird, aber wenn man nach der Schleife noch was machen möchte, was nicht in den Finally-Abschnitt gehört, dann ist es nicht das gleiche.


Oder meintest du mein Terminate vor der Schleife?
Das war nur zu Testzwecken drin, damit sich der Thread gleich wieder beendet, und ich somit testen konnte ob irgendeine andere Procedure für den Fehler verantwortlich war.

Zitat von ensaron:

Hallo Captnemo,

vielleicht gibt es einen Konflikt beim Empfangen von Messages? Wenn die Messagenummer für ICS nicht explizit auf einen Startwert gesetzt wird, benutzt ICS als erste Nummer WM_USER + 1 . Ich bin mir zwar nicht sicher, ob das zu einem Problem führen kann, aber den ICS-Messages einen Startwert zu geben, kann ja nicht schaden.
Um den Startwert zu setzen, benutze die Variable GWndHandlerMsgLow in der Unit OverbyteIcsWndControl , bevor du deine erste ICS-Komponente erzeugst.

Grüße
Thomas

Da du dich ja offensichtlich mit TWSocket schon tiefer befasst hast, noch mal eine kleine Nebenfrage.
Ich schicke zeilenweise (TCP) mit Linemode=Enabled und Lineend=#13#10.
Leider kommt aber beim Empfänger nicht immer die vollständige Zeile an. Zu 80% ist alles richtig und zwischendurch werden Zeichen "verschluckt", und zwar immer am Anfang der Zeile.
Ist der Linemode hier grundsätzlich sicher? Bzw. auf der anderen Seite das OnDataAvailable?