Um den Fehler mit den gleichen DateTime Werten zu lösen, sollte man sich die Frage stellen, was macht TQueue.Peek
"Guckt" nach dem obersten Element im Stapel, ohne es zu entfernen, im Gegensatz zu Dequeue.
und danach sollte man sich die Frage stellen, was für ein Wert steht denn in so einem TDateTime
.
So an und für sich ein Double, daher ist die Prüfung auf Ungleichheit doch okay, oder?
Und wenn der aktuelle Wert ungleich dem Peek-Wert ist, trägst du das in die Queue ein
So war das gedacht...habe ich hier schon einen Denkfehler?
Manchmal sehe ich den Wald vor lauter Bäumen nicht.
Das ist mit dem Dauerlauf des Thread ein schönes Feuerwerk
Na ja, das wäre ja nur ein Nebenaspekt in diesem Beispiel.
Ein liebevoll eingestreutes try-finally mit Sleep(100) oder meinetwegen auch ein Event kann dem Abhilfe schaffen, löst aber nicht das grundsätzliche Problem.
In
procedure TMessageThread.DoSendMessage(const ADateTime : TDateTime);
wird jedes Mal eine neue Instanz erzeugt, nur im Empfänger
procedure TForm1.OnNewDateTimeMessage(const Sender : TObject; const M : TMessage);
kommt es häufig vor, dass die gleiche Instanz empfangen wird.
Aber warum?
Zitat von
Mavarik:
Warum einen Thread für den Empfang?
Rein akademisches Interesse, sonst hätte ich ja auch im OnIdle direkt ins Memo schreiben können.
Mir ging es um die Threadübergreifende Kommunikation mithilfe des
RTL-eigenen MessageManagers.