Ram voll :-(

[XXcD]

Hallo,
beim mehrfachen ausführen folgender Prozedur wird der Speicher immer voller gepackt und dann gibt es nur noch Fehlermeldungen:

Delphi-Quellcode:

procedure TGame.ComboBox1Change(Sender: TObject);
begin
Image2.Picture.Bitmap.LoadFromFile(extractfilepath(paramstr(0))+'\Ressources\images\Player\'+ComboBox1.Text+'.bmp');
Image3.Picture.Bitmap:=split(Image2.Picture.Bitmap, 29, 34, 0, 0);
Image11.Picture:=Image3.Picture;
end;

Habs auch schon so versucht:

Delphi-Quellcode:

procedure TGame.ComboBox1Change(Sender: TObject);
begin
Image2.Picture.Free;
Image2.Picture.Bitmap.LoadFromFile(extractfilepath(paramstr(0))+'\Ressources\images\Player\'+ComboBox1.Text+'.bmp');
Image3.Picture.Bitmap:=split(Image2.Picture.Bitmap, 29, 34, 0, 0);
Image11.Picture:=Image3.Picture;
end;

Das gibt aber schon von anfang an einen Fehler.
Also weiß vielleicht einer wie ich das hinkriege, dass der Speicher immer wieder geleert wird?

[Dax]

Delphi-Quellcode:

procedure TGame.ComboBox1Change(Sender: TObject);
begin
Image2.Picture.Free;
Image2.Picture.Bitmap.LoadFromFile(extractfilepath(paramstr(0))+'\Ressources\images\Player\'+ComboBox1.Text+'.bmp');
Image3.Picture.Bitmap:=split(Image2.Picture.Bitmap, 29, 34, 0, 0);
Image11.Picture.Assign(Image3.Picture);
end;

[XXcD]

Hmm das macht keinen Unterschied bleibt genau so.

[Dax]

Komisch :gruebel: Liegt das Speicherleck vielleicht an einer anderen Stelle des Programms? Mit FastMM4 oder einem anderen Memory Manager/Checker liesse sich das ganz einfach lokalisieren.

Nachtrag: ups. Da hab ich doch tatsächlich den falschen Code kopiert :ups: Das Image2.Picture.Free gehört da natürlich nicht hin, sonst zieht man dem Programm ja die Arbeitsgrundlage unter den Füssen weg.

[XXcD]

Ja im Taskmanager seh ich ja wie sich der Speicherverbrauch erhöht und immer wenn ich diese Funktion ausführe dann erhöht sich der Speicherverbrauch. Also kann der Fehler nur da liegen. Ich glaube der Fehler liegt genau an dieser Stelle:

Delphi-Quellcode:

Image2.Picture.Bitmap.LoadFromFile(extractfilepath(paramstr(0))+'\Ressources\images\Player\'+ComboBox1.Text+'.bmp');

[littleDave]

Delphi-Quellcode:

procedure TGame.ComboBox1Change(Sender: TObject);
begin
Image2.Picture.Free; // <--- ich glaub das ist das Problem.

// Versuch mal das hier
Image2.Picture := nil; // <--- intern wird der Rest durch die Setter-Methode der Property geregelt
// [...]
end;

[Christian Seehase]

Moin Zusammen,

der Setter von Picture ruft intern nur Assign auf also:

Delphi-Quellcode:

Image11.Picture:=Image3.Picture; 
// macht das gleiche wie
Image11.Picture.Assign(Image3.Picture);
// man spart nur den Aufruf des Setters

@littleDave:
Wenn man nil zuweist, wird intern, im Prinzip, ein FreeAndNil durchgeführt, also nur wenig mehr als .Free.


Beides gilt für D7 und D2006, wird also in D2005 auch so sein.

[littleDave]

Zitat:

Zitat von Christian Seehase

@littleDave:
Wenn man nil zuweist, wird intern, im Prinzip, ein FreeAndNil durchgeführt, also nur wenig mehr als .Free.
Beides gilt für D7 und D2006, wird also in D2005 auch so sein.

Das stimmt - intern wird auch nur .Free aufgerufen. Aber wenn man explizit := nil aufruft, weiß die Komponente, dass die Property .Picture gelöscht/resettet werden soll. Wenn man hingegen im Quelltext selber .Picture.Free aufruft, bekommt das die TImage-Komponente afaik nicht mit (vielleicht doch durch ein OnDestryEvent, weiß ich gerade nicht).
Beim direkten aufruf von .Free zeigt der Klassenpointer immer noch auf den alten Speicherbereich, was eigentlich zu einer Zugriffsverletzung führen sollte :gruebel:. Ich würd die := nil-Variante vorziehen, da dann der Rest von der TImage-Komponente erledigt wird (bzw. werden sollte).

[XXcD]

Ich habe den Fehler gefunden lag an der Funktion Split.

[RavenIV]

Zitat:

Zitat von XXcD

Ich habe den Fehler gefunden lag an der Funktion Split.

Ist das eine Funkton von Dir oder aus der VCL?
Was war denn falsch?
Vielleicht kann da noch jemand was draus lernen.