self.free

[user0]

Hallo!

Ich möchte ein Objekt sich selbst zerstöhren lassen:

Delphi-Quellcode:

procedure TSpielstein.Rausschmeissen();
begin
  // Irgendwelcher Code...
  self.Free;
  self := nil;
end;

Leider kommt dann der Fehler "Ungültige Zeigeroperation!".
Was ist der Fehler? :gruebel:

[faux]

Dazu gibt es doch den Deconstructor, oder? :gruebel:

Grüße
Faux

PS: Zerstören schreibt man ohne h :wink:

[RavenIV]

das geht nicht, Objekte sind keine Selbstmörder.

ernsthaft:
der Compiler hat recht. Ein Objekt kann sich nicht selber zerstören. Woher soll denn dann der Computer wissen, was er bei´m Destructor machen soll wenn dieser schon zerstört wurde? Das würde ja in einer endlosschleife enden...

gruessle

[Dax]

Zitat:

Zitat von RavenIV

das geht nicht, Objekte sind keine Selbstmörder.

Nun, da muss ich dich enttäuschen ;) Ich weiß nicht mehr genau wie ichs damals geschafft hab, aber ich habe ein Objekt sich selbst zerstören lassen ohne Fehler zu produzieren. Ich such mal den Code..

[user0]

Das währe toll!

Im Notfall muss ich wohl eine Variable definieren, die beschreibt, ob das Objekt noch aktiv ist, oder nicht, so dass das Besitzerobjekt seinen Besitz zerstören kann. :mrgreen:

[RavenIV]

Zitat:

Zitat von user0

Das währe toll!

Im Notfall muss ich wohl eine Variable definieren, die beschreibt, ob das Objekt noch aktiv ist, oder nicht, so dass das Besitzerobjekt seinen Besitz zerstören kann. :mrgreen:

eigentlich ist es ja auch so gedacht, dass der, der ein Objekt erzeugt, es wieder zerstören soll.

[sakura]

Zitat:

Zitat von Dax

Zitat:

Zitat von RavenIV

das geht nicht, Objekte sind keine Selbstmörder.

Nun, da muss ich dich enttäuschen ;) Ich weiß nicht mehr genau wie ichs damals geschafft hab, aber ich habe ein Objekt sich selbst zerstören lassen ohne Fehler zu produzieren. Ich such mal den Code..

Self.Free ist kein Problem, allerdings kannst Du die "imaginäre" Referenz "Self" nicht auf nil setzen. Self ist immer nur ein übergebener const-Parameter, der automatisch übermittelt wird.

...:cat:...

[Dax]

Na ja, man kann sich auch selbst zerstören: FreeInstance(). Nur selbst begraben (Self := nil) ist unmöglich..

Wie sakura schon gesagt hat ;)

[faux]

ABer wozu denn das alles? Normalerweise zerstört man das Objekt doch mittels dem Deconstructor, oder? Derjenige der ´die Klasse erzeugt, muss sie nach dem Verwenden auch wieder zerstören. Oder?

Grüße
Faux

[user0]

Es ist im Moment einfach einfacher.
Es geht um Spielfiguren, die sich gegenseitig rausschmeißen.

Zu FreeInstance:

Wie kann man herausfinden, ob ein Pointer "ins leere" zeigt?
Auf nil kann ich ja nicht setzen.

[RavenIV]

Zitat:

Zitat von faux

ABer wozu denn das alles? Normalerweise zerstört man das Objekt doch mittels dem Deconstructor, oder? Derjenige der ´die Klasse erzeugt, muss sie nach dem Verwenden auch wieder zerstören.

genau, so sehe ich das auch.

was macht self.free() denn für einen Sinn?
woher soll eigentlich das Objekt wissen, dass es nicht mehr benötigt wird?

[sakura]

Zitat:

Zitat von RavenIV

was macht self.free() denn für einen Sinn?
woher soll eigentlich das Objekt wissen, dass es nicht mehr benötigt wird?

Es gibt viele Möglichkeiten dafür. Ein einfaches Beispiel: ein Thread soll im Hintergrund ein Dokument drucken. Wenn der damit fertig ist, dann kann dieser sich ins Nirvana verabschieden - den braucht keiner mehr.

...:cat:...

[SMO]

Ich glaube hier stiftet der Unterschied zwischen Objekten und Referenzen wieder Verwirrung.

Ein Objekt kann viele Referenzen haben. Ein sich selbst zerstörendes Objekt sollte (müsste) alle Referenzen auf sich auf nil setzen. Das geht aber nicht so einfach, denn woher soll es die kennen? Beispiel:

Delphi-Quellcode:

var
  A, B, C: TObject;

A := TObject.Create;
B := A;
C := B;

Damit hätte man ein Objekt aber drei Referenzen darauf. Wenn das Objekt nun zerstört wird, z.B. durch B.Free, dann hat der Destruktor noch nicht mal Kenntnis von B, geschweige denn von A und C. Der "Self" Parameter, der in den Methoden verfügbar ist, ist ein Zeiger auf das Objekt (seine Datenstruktur) und nicht ein Zeiger auf eine der Referenzen.
Genau deshalb gibt es ja z.B. "FreeAndNil". Das ruft Free auf und setzt die übergebene Referenz auf nil. Falls noch andere Referenzen auf das Objekt existieren bleiben sie davon natürlich unberührt.

[user0]

Ebend deshalb will ich wissen, wie man herrausfindet, ob ein Zeiger ins Nichts zeigt. :coder:

[RavenIV]

Zitat:

Zitat von sakura

Zitat:

Zitat von RavenIV

was macht self.free() denn für einen Sinn?
woher soll eigentlich das Objekt wissen, dass es nicht mehr benötigt wird?

Es gibt viele Möglichkeiten dafür. Ein einfaches Beispiel: ein Thread soll im Hintergrund ein Dokument drucken. Wenn der damit fertig ist, dann kann dieser sich ins Nirvana verabschieden - den braucht keiner mehr.

ein Thread ist kein Objekt.
ein Thread wird gestartet und beendet (beendet sich selbst).
ein Objekt wird erzeugt und zerstört.

[dizzy]

Das geht nur über Prüfung auf Zeiger=nil, was aber wiedrum nicht geht, da du bei der angestrebten Variante eben dies nicht machen kannst ;). Ein Zeiger zeigt wenn er nicht nil ist IMMER auf irgendwas. Im schlimmsten Fall halt auf "zufällige" Daten, oder in geschützte Segmente.
Eine Variante die mir einfiele wäre es der Prozedur "Rausschmeissen" die entsprechende Referenz nochmals als var-Parameter mit zu übergeben:

Delphi-Quellcode:

procedure TMyClass.Rausschmeissen(var p: TMyClass);
begin
  p := nil;
  self.Free;
end;

Damit wäre aber nur diese eine übergebene Referenz nil. Jede weitere auf dieses Objekt ist immernoch ungültig nachher.

[tommie-lie]

Zitat:

Zitat von RavenIV

ein Thread ist kein Objekt.

Wenn ich ihn mit BeginThread() starte nicht, richtig, aber eine TThread-Instanz ist ein Objekt (Gips nicht sogar ein Property TThread.FreeOnTerminate?).

Zitat:

Zitat von user0

Es geht um Spielfiguren, die sich gegenseitig rausschmeißen.

So?

Delphi-Quellcode:

TPawn = class
public
  destructor Destroy();

  procedure Capture(var TSpielfigur: aPawn);
  procedure Move(Integer: x, y);
end;


procedure TPawn.Capture(var TPawn: aPawn)
begin
  aSpielfigur.Free;
  aSpielfigur := nil;
  self.Spieler.IncreasePoints(1);
end;

destructr TPawn.Move(x, y)
begin
  if Board[x,y].getPawn() <> nil then // da steht schon jemand
    if Board[x,y].getPawn().getPlayer() <> self.getPlayer then // und der jemand gehört nicht mir
      self.Capture(Board[x,y].getPawn()); // also sacke ich den ein
end;

Keine Ahnung ob die Syntax stimmt, aber laufen müsste es, selbst wenn es sich nicht kompilieren lässt :mrgreen:
Wenn die Spielfigur noch irgendwas hat, was sie freigeben möchte, zum Beispiel irgendwelche Ausrüstung, die die schlagende Spielfigur vorher nicht an sich nimmt, kann sie das im Destruktor tun. Wenn sie sich vorher in irgendeinem Kontrollobjekt "abmelden" muss, kann sie das ebenfalls im Destruktor tun.

[berens]

Tja, genau das Problem habe ich auch gerade:

Stellt euch vor -als Beispiel- ich würde ein Notizzettelprogramm schreiben. Jeder vom Benutzer erstellte Notizzettel (meine Komponente) hat einen "Löschen" Knopf.

Wenn bei der Aktion des Buttons Self.Parent.Free aufgerufen wird, führt das zwangsläufig zu einem Programmabsturz.

Deshalb meine Frage: Wir macht man das sauber? Hab ihr noch nie Komponenten gehabt, die der Benutzer zu Laufzeit erstellen und auch wieder löschen kann?

Wie kann die erstellende Komponente den einzelnen Notizzettel löschen, wenn auf JEDEM Zettel selbst ein Löschen Knopf ist?



Edit: http://www.delphipraxis.net/internal...self+self+free

hat mir den Tag gerettet. Das ist doch alles was ich wollte :)

Evtl "Self" statt "Sender" benutzen.
PostMessage(Self.Handle, WM_KILL_CONTROL, 0, Integer(Self));

[faux]

Aber du greifst ja über die Form auf die Komponente zu und nicht über sich selbst, oder?
Du erstellst die Komponente ja auch nicht über self.Create... :roll:
Über die Klasse, in der du sie erstellst (zB TForm1), in dieser kannst du sie auch wieder Freigeben.

Grüße
Faux

[berens]

*gnaaa* Sorry, aber die Antwort steht schon in allen anderen Threats drinnen, und ich kann die Logik davon ja nachvollziehen, aber wie sieht es mit der praktischen Umsetzung aus? Wenn JEDER Notizzettel (der ja ne eigene Komponente mit nem eigenen "Löschen" Knopf ist) halt einen Löschen Knopf hat, wie setze ich dass logisch um? Wenn "Löschen" auf den aktuellen Zettel angeklick wird, muss ja dann (wenn der Zettel gelöscht wird) auch logischerweise der Löschen Knopf gelöscht werden.
Wie setze ich das um?

Klick --> Benachrichtigung an Form --> löschen durch das Form klappt ja nicht, weil der auslöser der Löschen funktion ja wiederrum mein Löschen Knopf ist.... Zirkelbezug ohne Ende...

[xaromz]

Hallo,

Zitat:

Zitat von berens

Klick --> Benachrichtigung an Form --> löschen durch das Form klappt ja nicht, weil der auslöser der Löschen funktion ja wiederrum mein Löschen Knopf ist.... Zirkelbezug ohne Ende...

Ist doch ganz einfach:
Klick -> Message an Form -> Funktion wird beendet -> Message wird verarbeitet -> Form löscht Zettel.

Gruß
xaromz

[berens]

Ja aber wir genau mach ich des?

Wenn ich einen Pointer/Variable auf das zu löschende Objekt setze und dann beim zuweisen (Property write) das ändere, ist der auch noch mitten in der OnClick procedure des Löschen Buttons.

procedure TMeineKompo.cmdDeleteClick(Sender: TObject);
begin
form1.KompoDieDuLöschenSollst := Self;
end;

klappt also nicht, da ja direkt beim zuweisen die TMeineKomponente gelöscht wird...

Wie würde dass ganze denn in etwa (Quellcodetechnisch?) ablaufen?

[xaromz]

Hallo,

ungefähr so:

Delphi-Quellcode:

unit Unit1;

const
  CM_LOESCHEN = WM_USER + 24;

type
  TForm1 = class(TForm)
  ...
  procedure CMLOESCHEN(var Message: TMessage); message CM_LOESCHEN;
  ...

procedure TForm1.CMLOESCHEN(var Message: TMessage);
begin
  TObject(Message.wParam).Free;
end;

Delphi-Quellcode:

unit Unit2;

type
  TZettel = class(TForm)
  ...
  procedure DeleteClick(Sender: TObject);
  ...

procedure TZettel.DeleteClick(Sender: TObject);
begin
  SendMessage(Form1.Handle, CM_LOESCHEN, Integer(Self), 0);
end;

Gruß
xaromz

[berens]

Danke, genau sowas hab ich gesucht, is ja was vergleichbares wie der Link zu dem anderen Thema weiter oben.

Das ist nur halt problematisch wenn man selbst noch nie direkt mit Messages gearbeitet hat ;)

Danke für die Info, ich denke damit kann man gut was anfangen. :-D