Danke für Deine Antwort,

Wenn ich ReportMemoryLeaksOnShutdown := True verwende, poppt kein Fenster auf, das mich darüber informiert, wie schlecht ich programmiere, also gehe ich davon aus, zumindest keine allzu offensichtlichen Speicherlöcher zu hinterlassen

Seltsam, sobald ich die Synchronize-Methode auskommentiere, läuft das Programm "stundenlang" fehlerfrei:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TDisplayHandler.Execute;
begin
  while not Terminated do
  begin
    if not FIsDone then
    begin
      DoCreate;
     // Synchronize(SyncEvent); //wenn das auskommentiert ist, läuft das Programm
      FIsDone := True;
    end
    else
      Sleep(20);
  end;
end;

Mit anderen Worten: Das Bitmap wird nach wie vor "bemalt", jedoch nicht mehr per Assign in das Image der MainForm "kopiert",
das schließt mMn einen Fehler bei der "Speicherzumüllung" aus.
Also muss mMn ein Fehler bei der Übergabe an die GUI passieren, obwohl der Zugriff darauf synchronized ist?

Ah halt, er sagt ja auch „System Resources“ und nicht „Memory“.

Da fällt mir ein, ich hatte glaube ich vor gar nicht all zu langer Zeit ein ähnliches Problem – ich bin mir nicht mehr 100%ig sicher, aber ich glaube es war so, dass GDI-Objekte immer einem bestimmten Thread angehören. D.h. du kannst sie nicht im einen Thread erzeugen und in einem anderen verwenden, bzw. es kann dann zu Fehlern kommen. Genau das tust du aber, weil der contructor des Threads noch im Hauptthread ausgeführt wird.

Schieb die Erzeugung von FBitmap mal vom constructor in die Execute-Methode (und die Freigabe natürlich auch).

Gerade im fraglichen Projekt, wo der Fehler bei mir auftrat, noch mal nachgeschaut. Vergiss das mit dem constructor. Du musst einfach nur Canvas.Lock/Unlock vor und nach deinen Zeichenoperationen aufrufen. Das war des Rätsels Lösung.

Edit²: Hat zumindest bei mir gereicht.

Zitat von NamenLozer:

... aber ich glaube es war so, dass GDI-Objekte immer einem bestimmten Thread angehören. ...

Genau das ist es. Windows-GDI-Ressourcen sind Thread-Affine. D.h. auf sie darf nur im erzeugenden Thread zugegriffen werden. Ansonsten kracht irgendwo irgendwas.

Zitat von NamenLozer:

Gerade im fraglichen Projekt, wo der Fehler bei mir auftrat, noch mal nachgeschaut. Vergiss das mit dem constructor. Du musst einfach nur Canvas.Lock/Unlock vor und nach deinen Zeichenoperationen aufrufen. Das war des Rätsels Lösung.

Edit²: Hat zumindest bei mir gereicht.

Anscheinend nicht nur bei Dir...
Seltsam, seltsam...

Zitat von Bernhard Geyer:

Zitat von NamenLozer:

... aber ich glaube es war so, dass GDI-Objekte immer einem bestimmten Thread angehören. ...

Genau das ist es. Windows-GDI-Ressourcen sind Thread-Affine. D.h. auf sie darf nur im erzeugenden Thread zugegriffen werden. Ansonsten kracht irgendwo irgendwas.

OK, wieder was gelernt.

Auf jeden Fall vielen Dank für Eure Antworten,
andere Baustellen rufen mich jedoch , da jetzt diese anscheinend begradigt wurde