Systemressourcen erschöpft

[himitsu]

keine Sorge ... TBitMap ist ein Object und die haben ja keine Referenzzählung (wobei man diese als Objekte auch eigentlich nicht nach Pointer casten muß, um sie irgendwo abzuspeichern/abzulegen)

[jaenicke]

Zitat:

Zitat von himitsu

keine Sorge ... TBitMap ist ein Object und die haben ja keine Referenzzählung

Ja, dafür müssen sie explizit freigegeben werden.
Ich hatte irgendwie gerade Strings im Hinterkopf als ich das geschrieben habe. :gruebel:

[stahli]

Ich habe den Übeltäter :-)

Delphi-Quellcode:

procedure TDPerson.ClearPicture;
begin
  if Assigned(FPicture) then // neu eingeführt
  begin
    FreeAndNil(FPicture);
    FPicture := TBitmap.Create;
    DataChanged;
  end;
end;

Um Bilder "zu löschen" habe löse ich das Bitmap auf und erzeuge ein neues (Bitmap.Clear gibt es ja nicht).
Diese Methode wurde auch aufgerufen bevor das Bitmap das erste mal erzeugt wurde :oops:
Jetzt schließe ich das mit Assigned aus.

Das Hauptproblem scheint geklärt :-)

Danke für die Hilfe!

Stahli

[Luckie]

Wen du so vile Unterformulare hast, würde ich die auch nicht beim Programmstart alle automatisch erzeugen lassen, sondern zur Laufzeit dynamisch erzeugen.

[stahli]

Ja, das mache ich auch.
Ich löse sie dann allerdings nicht wieder auf, da sie immer mal wieder gebraucht werden.
Für den Notfall merke ich mir das als Option vor.
Nach Klärung des Bitmap-Problems läuft allerdings nun alles perfekt! :-)

[Luckie]

Zitat:

Zitat von stahli

Ich löse sie dann allerdings nicht wieder auf, da sie immer mal wieder gebraucht werden.
Für den Notfall merke ich mir das als Option vor.

Das würde ich dann allerdings als unsauber betrachten. Wenn du sie schon dynamisch erzeugst, dann mach es auch richtig und gib sie wieder frei, wenn sie geschlossen werden.

[stahli]

Kurz zu meinem Konzept dazu:

Die Unterformulare diesen der Datenbearbeitung von Komponenten.
VCustom.FormEdit

Die Methode VCustom.Select öffnet weist der Eigenschaft je nach Situation ein Bearbeitungsformular zu, positioniert und öffnet dieses.
Wurde das betreffende Bearbeitungsformular bisher noch nicht benutzt wird es erzeugt (Eigentümer ist die Application).

Das Formular schließt sich i.d.R. automatisch, wenn es deaktiviert wird.

Aufgelöst wird es, wenn die Application beendet wird.

Die Unterformulare werden imnmer wieder benötigt, daher löse ich sie nicht sofort auf und das führt ja (offenbar) auch nicht zu Problemen...

[mjustin]

Zitat:

Zitat von stahli

@mjustin:
Danke! D2006 bringt da ja schon einen eigenen Ansatz mit (siehe Bild).

Das ist der Leak Report Bildschirm von FastMM4, dem (Open Source) Memory Manager, der von CodeGear in Delphi integriert wurde. Also eigentlich nix eigenes, sondern eher etwas <borg>assimiliertes</borg> :wink: - und für mich eine der besten Neuerungen an Delphi seit Version 7.

[stahli]

Also ich habe jetzt FastMM4 installiert und nutze den FullDebugMode.

So habe ich noch einige weitere Fehler gefunden, bei denen ich über Referenzen auf bereits aufgelöste Objekte deren Methoden aufgerufen habe.
Das habe ich vorher gar nicht bemerkt!

Es ist zwar (auch mit dem Textreport) nicht einfach, die betreffenden Fehler aufzuspüren, aber man erhält ein paar gute Anhaltspunkte.

Es ist also bei komplexeren Programmen wohl unbedingt sinnvoll, FastMM oder Ähnliches zu verwenden. Wäre natürlich auch nicht verkehrt, wenn Delphi so eine Speicherkontrolle selbst durchführen würde.

Welche Alternativen gibt es zu FastMM. Was sind die Vor- und Nachteile?

Stahli

[Bernhard Geyer]

Zitat:

Zitat von stahli

Es ist zwar (auch mit dem Textreport) nicht einfach, die betreffenden Fehler aufzuspüren, aber man erhält ein paar gute Anhaltspunkte.

Hast Du TD32-Debug-Infos aktiv?

Zitat:

Zitat von stahli

Wäre natürlich auch nicht verkehrt, wenn Delphi so eine Speicherkontrolle selbst durchführen würde.

Hat es doch jetzt :-)