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.

Grad gefunden:

Zitat:

To have the TTimer.OnTimer event be triggered in the context of the worker thread, you have to instantiate the TTimer inside the thread's Execute() method instead. But that has another set of pitfalls. TTimer creates a hidden window using AllocateHWnd(), which is not thread-safe and cannot safely be used outside the context of the main thread. Also, TTimer requires the creating thread context to have an active message loop, which your thread does not.

Quelle: http://stackoverflow.com/questions/1...d-generates-av



Gibt's nen Timer der Threadsafe ist?

Ist der JvThreadTimer Theadsafe?

Zitat:

This component is a replacement for the TTimer component with a better accuracy (1 millisecond) and without consuming a window handle for the timer. TJvThreadTimer uses an internal thread instead of the Windows API timer functions, and can have an accuracy of a millisecond, but it will consume more CPU than a TTimer.

http://wiki.delphi-jedi.org/wiki/JVC...TJvThreadTimer
Versteh ich das richtig?

TTimer verwendet die Funktion setTimer von Windows. Du könntest das manuell versuchen.