Record New/Dispose resultiert in MemoryLeaks

[p80286]

Eben drum habe ich da Bauchschmerzen!

Gruß
K-H

[Glados]

Ich muss in manchen Fällen 3 verschiedene Dateninformationen schicken.

2 davon sind für die GUI, die dritte für ein case-of. Das funktioniert aber leider nur mit dem WndProc() MessageHandler.
Mit einem eigenen wäre mir das lieber, dadurch verliere ich aber von den 3 Plätzen schonmal einen, um den MessageHandler anzugeben.

Daher die Record-Geschichte.

[Uwe Raabe]

Zitat von Der schöne Günther:

Die Windows Message Queue ist 10.000 Einträge groß, da passen natürlich die anderen 40.000 nicht mehr rein.

In dem Fall könnte es helfen, den Rückgabewert von PostMessage zu prüfen und im Fehlerfall den Record selbst wieder freizugeben.

[Dalai]

Zitat von p80286:

Oder bin ich da auf dem falschen Gleis?

Ich hatte kürzlich mit dem Versenden und Empfangen von Nachrichten zwischen zwei Formularen zu tun, und habe dazu Folgendes gelesen: Der Sender der Nachricht muss sicherstellen, dass der Empfänger mit der Nachricht auch etwas anfangen kann. Das heißt, sofern da ein Zeiger auf irgendeine Datenstruktur versendet wird, muss dieser bis zum Ende der Verarbeitung der Nachricht gültig sein. Ich weiß nicht, wie das bei einem solchen Konstrukt funktionieren soll, ob das Ziel des Zeigers nach dem Verlassen der Methode noch sinnvolle Daten enthält. Insofern teile ich deine Bedenken.

@Glados:
Von wo nach wo werden denn die Nachrichten versendet? Von einem Formular zum anderen? IIRC ist es doch so, dass solche Nachrichten gar nicht in der Message Queue von Windows landen sondern direkt vom Formular verarbeitet werden. Andererseits passt die Anzahl der Lecks exakt zu dem Limit der Message Queue von 10k ...

Grüße
Dalai

[Glados]

Das mit dem 10.000-Limit wusste ich nicht.
Dann wäre es glaube ich das Beste, wenn ich das mit dem Record sein lasse und Strings stattdessen so mitschicke
PostMessage(receiver, command, wParam, LPARAM(PChar('string'))); Ich schicke aus einem Thread heraus.

Habe meinen Branch vorsichtshalber mal hard-resetet. Ich denke eine andere Lösung ohne records ist doch wesentlich besser.

Eine eigene MessageQueue ohne das 10.000-Limit ggf. Aber das ist sicher nicht möglich.

[Zacherl]

Zitat von Glados:

Das mit dem 10.000-Limit wusste ich nicht.
Dann wäre es glaube ich das Beste, wenn ich das mit dem Record sein lasse und Strings stattdessen so mitschicke
PostMessage(receiver, command, wParam, LPARAM(PChar('string')));

Das klappt auch ausschließlich mit String-Konstanten.

Im Falle von:

Delphi-Quellcode:

var
  S: String;
begin
  S := 'blabla';
  PostMessage(receiver, command, wParam, LPARAM(PChar(@S[1])));
  // ...
  S := '123';

kannst du nie sicher sein, ob S noch 'blabla' oder schon '123' enthält, wenn deine Nachricht bearbeitet wird. Selbes gillt natürlich für den Falle, dass der Thread den String in jeder Iteration modifiziert.

Ich kann dir nur nochmal raten von dem ganzen Message Gefummel zurück zu TThread.Queue zu wechseln. Da musst du dir weder um manuelle Speicherverwaltung, noch um irgendwelche Message-Queue Limits oder andere Edgecases Gedanken machen.

[Glados]

Zitat:

Ich kann dir nur nochmal raten von dem ganzen Message Gefummel zurück zu TThread.Queue zu wechseln. Da musst du dir weder um manuelle Speicherverwaltung, noch um irgendwelche Message-Queue Limits oder andere Edgecases Gedanken machen.

Ich versuche meine vorhandenen Codefragmente mal in Prozeduren zu packen und das so zu machen.

Jedoch würde ich aus den Threads eine Prozedur in einer anderen Unit aufrufen (mit Übergabe der Thread-ID), um einige unnötige Zeilen (Queue(nil{* <= kommt hier dann die Thread-ID hin? *}, procedure begin end); ) zu sparen.

Ich melde mich sobald ich alles umgebaut habe.

[Zacherl]

Statt der ThreadId, musst du die Instanz des aufrufenden Threads also Self als Parameter vom Typ TThread übergeben, aber dann sollte es ohne Probleme funktionieren die Funktion auszulagern

[Glados]

Ok danke ich melde mich