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.

Zitat von mkinzler:

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

TTimer oder ein eigenes MessageOnlyWindow+SetTimer bringt nichts, solange die "komplette" Bahandlung nicht auf einen der beiden Threads beschränkt wird.

Zitat von Captnemo:

Grad gefunden:

Siehe hatte es auch grade noch so gesehn und meinen Beitrag oben erweitert.
Vorallem das Fette und Nachfolgendes.

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.

Ja, das Break verlässt die Schleife und das Exit auch.
Im Grunde wollte ich nur sagen, daß die Execute-Methode bei allen 3. Varianten verlassen (Exit sagt das nur deutlicher, zum Programmierer) und der Thread beendet wird.

Zitat:

Oder meintest du mein Terminate vor der Schleife?

Jupp, genau das.



Ob der TJvThreadTimer threadsave ist, weiß ich nicht, aber ich glaub das "Thread" im Namen sagt erstmal nur aus, wie er intern arbeitet.

TTimer geht über SetTimer und wartet auf die WM_TIMER.
Und der TJvThreadTimer erzeugt einen Thread, in dem er die Millisekunden wartet und dann das Ereignis manuell auslöst, ohne über die MessageQueue zu gehen.