Component.Free -> auch fremde Zeiger auflösen

[stahli]

Das Problem ist früher schon besprochen worden.
Gibt es inzwischen eine (Delphi-)Löung, die ich noch nicht kenne?

Delphi-Quellcode:

Panel1 := TPanel.Create(Self);
Panel2 := Panel1;
Panel1.Free; // bzw. FreeAndNil(Panel1);
//... irgendwann später
if Assigned(Panel2) then
  Panel2.Caption := 'Exception!!!' // geht natürlich nicht mehr

Ich habe mir mal die Quelle von TObjectList angesehen und sogar fast komplett verstanden, wie das da funktioniert. :wink:

Gibt es inzwischen eine Möglichkeit, auch einzelne Komponenten an andere zu binden?
Panel2 soll automatisch auf nil gesetzt werden, wenn Panel1 freigegeben wird.

Ein nützliches Feature wäre das sicher...

[Uwe Raabe]

Smart Pointer nennt man das - gibt es aber in Delphi von Haus aus nicht.

[r2c2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1047560)

Smart Pointer nennt man das - gibt es aber in Delphi von Haus aus nicht.

Und ist auch schwierig nachzubauen, da Delphi keine Kopierkonstruktoren kennt. Man braucht sowas aber auch kaum, wenn man es richtig angeht.

==> Sag mal, für was du das brauchst. Vielleicht gibts nen besseren Weg...

mfg

Christian

[stahli]

Ich habe selbst eine Lösung gebaut, die aber nur für meine "speziellen" Komponenten funktioniert (also nicht für Standardkomponenten, was sicher mal eine gute Sache für künftige Delphi-Versionen wäre - ähnlich, wie es mit TObjectList eingeführt wurde).

Ich habe sichtbare Komponenten (Tsc), die Datenkompnenten (Tdc) verwenden. Die DC werden in benötigter Menge erzeugt und beliebig viele SC können auf ein unbd die selbe DC zugreifen, um die Daten zu verwenden (anzeigen + ändern).

Wird durch die Geschäftslogik eine DC gelöscht, erfahren das die SC nicht automatisch.

Delphi-Quellcode:

DC.Free

sollte für alle existierenden SC, bei denen SC.DC = freigegebeneDC ist

Delphi-Quellcode:

SC.DC := nil

setzen.

Ich mache das selbst, indem ich alle SC in einer TComponentList sammle und die "Nilung" im Tdc.Destroy selbst veranlasse.

Eine grundsätzliche Lösung hielte ich jedoch für nützlich.
Für "normale" Variablen halte ich eine Umsetzung auch für möglich (ähnlich TComponentList), sofern Propertys mit Getter und Setter-Methoden "genilt" werden müssen, wird es aber sicher deutlich schwieriger.

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1047615)

Ich habe sichtbare Komponenten (Tsc), die Datenkompnenten (Tdc) verwenden. Die DC werden in benötigter Menge erzeugt und beliebig viele SC können auf ein unbd die selbe DC zugreifen, um die Daten zu verwenden (anzeigen + ändern).

Wird durch die Geschäftslogik eine DC gelöscht, erfahren das die SC nicht automatisch.

Delphi-Quellcode:

DC.Free

sollte für alle existierenden SC, bei denen SC.DC = freigegebeneDC ist

Delphi-Quellcode:

SC.DC := nil

setzen.

Und was veranlasst dich dazu die DC-Dinger freizugeben und die SCs nicht?

mfg

Christian

[stahli]

Die DC-Dinger verwalten alle Projektdaten (im Grunde XML-Knoten) und die eigentliche Geschäftslogik.
Dort können Methoden angeschoben werden, die neue DC-Komponenten erstellen oder welche löschen.

Die GUI wird danach neu gezeichnet und muss dann neue SC-Komponenten erzeugen oder nicht mehr benötigte löschen.
Wenn sich die SC´s dann zeichnen wollen und auf eine inzwischen freigegebene DC zeigen, macht das natürlich Probleme.

Also meine Lösung funktioniert schon zuverlässig, ich wollte nur mal nachfragen, ob es inzwischen doch vielleicht eine automatische Lösung gibt.

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1047623)

Die DC-Dinger verwalten alle Projektdaten (im Grunde XML-Knoten) und die eigentliche Geschäftslogik.

Gut so. Ich frag mich zwar, warum das Komponenten sein müssen - normale Klassen würden doch auch tun - aber die Trennung ist gut so.

Zitat:

Dort können Methoden angeschoben werden, die neue DC-Komponenten erstellen oder welche löschen.

Das ist auch noch relativ normal. Kommt natürlich drauf an, was die DC-Dinger nun darstellen.

Zitat:

Die GUI wird danach neu gezeichnet und muss dann neue SC-Komponenten erzeugen oder nicht mehr benötigte löschen.

Das sieht mir so aus, als bräuchtest du eine Zwichenschicht, vielleicht ein Builder Pattern oder sowas.

Zitat:

Wenn sich die SC´s dann zeichnen wollen und auf eine inzwischen freigegebene DC zeigen, macht das natürlich Probleme.

Und das sagt mir, dass vielleicht was mit Bindung und Kopplung nicht stimmt. Die Abhängigkeiten kommen mir komisch vor. Überdenke ggf. mal dein Konzept.

Zitat:

Also meine Lösung funktioniert schon zuverlässig, ich wollte nur mal nachfragen, ob es inzwischen doch vielleicht eine automatische Lösung gibt.

Nein, die gibt es nicht und wird es vermutlich auch nie geben. Das hängt einfach damit zusammen, wie Delphi konzipiert ist...

mfg

Christian

[stahli]

Also meine DC´s haben unterschiedliche Eigenschaften und Methoden.

Ein Spieler hat einen Vornamen und Namen und kann einen FullName "berechnen".
Eine Mannschaft hat selbst einen Namen und kann 0..n Spieler beinhalten.

Es gibt also Einfache DC und Listen-DC.
Jede DC besitzt einen XML-Knoten, über den die Daten verwaltet werden.

Die Datenschicht (Funktionen, die die DC zum Lesen und schreiben verwenden) setzen alle SC's (die bis zu ihrer Auflösung in einer Liste gesammelt werden) auf Invalidate;

Diese werden also bei Gelegenheit neu gezeichnet und holen sich dabei die aktuellen Werte aus "ihren" XML-Knoten.
Die Listenkomponenten aktualisieren dabei auch ihre Items, erzeugen neue (bei neuen Datensätzen) oder löschen überzählige (bei gelöschten Datensätzen).

Windows kann aber in diesen Fällen auch mal ein Item (abgeleitet von TPanel) neu zeichnen wollen, bevor die übergeordnete Listenkomponente sie gelöscht hat.
Die Controls sind ja eigentlich unabhängig voneinander.

Und das Problem löse ich über das Auflösen des Daten-Zeigers einer SC, wenn dessen DC nicht mehr gülig ist.


Grundsätzlich werden immer nur sichtbare Bereiche aktualisiert, wenn Änderungen in der Datenschicht erfolgt sind.
So kann ich z.B. auch einer sichtbaren Mannschaft Mannschaft A zuweisen (10 Spieler werden angezeigt) und dann Mannschaft B (die Anzeige wird auf 8 aktualisiert).


Danke für die Hilfe!

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1047633)

Also meine DC´s haben unterschiedliche Eigenschaften und Methoden.

Das ist normal. Absolut normal.

Zitat:

Ein Spieler hat einen Vornamen und Namen und kann einen FullName "berechnen".
Eine Mannschaft hat selbst einen Namen und kann 0..n Spieler beinhalten.

Gut!

Zitat:

Es gibt also Einfache DC und Listen-DC.

Joa... ==> Aggregierende Objekte. Deine Klassifizierung ist etwas merkwürdig und führt leicht in falsche Denkstrukturen, aber vom Prinzip her OK.

Zitat:

Jede DC besitzt einen XML-Knoten, über den die Daten verwaltet werden.

Das könnte man entkoppeln, was etwas schöner wäre. Aber auch das ist noch OK. Kann man so machen.

Zitat:

Die Datenschicht (Funktionen, die die DC zum Lesen und schreiben verwenden) setzen alle SC's (die bis zu ihrer Auflösung in einer Liste gesammelt werden) auf Invalidate;

Peng! Kapitalfehler. Genau *das* dürfen Schichten nämlich nicht. Eine untere Schicht darf *niemals* auf eine höhere zugreifen. Genau das heißt nämlich "Schicht". Eine Anwendung, die in Schichten organisiert ist, ist immer hierarchisch. Die unteren Schichten wissen gar nicht, dass es die oberen gibt. Und erst recht ändern sie da nix. Es passiert immer umgekehrt: Die oberen Schichten benutzen die unteren.

Was aber, wenn die oberen darauf reagieren müssen, wenn auf den unteren Schichten was passiert? Dafür gibt es Indirektionsmechanismen. Also Events oder beispielsweise das Observer-Pattern.

Zitat:

Diese werden also bei Gelegenheit neu gezeichnet und holen sich dabei die aktuellen Werte aus "ihren" XML-Knoten.

OK.

Zitat:

Die Listenkomponenten aktualisieren dabei auch ihre Items, erzeugen neue (bei neuen Datensätzen) oder löschen überzählige (bei gelöschten Datensätzen).

Auch OK.

Zitat:

Windows kann aber in diesen Fällen auch mal ein Item (abgeleitet von TPanel) neu zeichnen wollen, bevor die übergeordnete Listenkomponente sie gelöscht hat.
Die Controls sind ja eigentlich unabhängig voneinander.

Ganz böse. Du hast hier eine Abhängigkeit erzeugt, die dir sehr lustige Probleme bereiten kann.

Zitat:

Und das Problem löse ich über das Auflösen des Daten-Zeigers einer SC, wenn dessen DC nicht mehr gülig ist.

Jein. Du löst das Problem nicht, du umgehst es. Du klebst notdürftig einen Flicken drauf. Das Problem ist, dass du Invalidate für etwas verwendest, für das es nicht gedacht ist. Invalidate sagt nur "zeichne dich neu", nicht aber "es gibt neue Daten". Du verpasst dem eine neue Semantik und das ist gefährlich. Dadurch kriegst du Abhängigkeiten, die sich auf die Nebenläufigkeit auswirken. Du reparierst das Ganze, indem du die nebenläufigen Fälle separat behandelst. Das setzt voraus, dass du wirklich alle bedenkst. Deine Software wird, wenn sie wächst, ggf. neue nebenläufige Ausführungspfade haben, die du alle bedenken musst. Und wie Murphy so will, wirst du vermutlich irgendwann einen dieser Fälle nicht bedenken und du hast nen extrem schwer zu findenden Bug. Oder zwei. Oder drei. Oder mehr. So Konstruktionen sind gefährlich und tendenziell Bugschleudern.

Zitat:

Grundsätzlich werden immer nur sichtbare Bereiche aktualisiert, wenn Änderungen in der Datenschicht erfolgt sind.

"Premature optimization is the root of all evil in programming." -- Donald Knuth (wohl Hoare zitierend)

mfg

Christian

[uligerhardt]

Vielleicht ist TComponent.Notification oder TComponent.FreeNotification was für dich.

[stahli]

@ Christian

Zitat:

Das könnte man entkoppeln, was etwas schöner wäre. Aber auch das ist noch OK. Kann man so machen.

Wie meinst Du "entkoppeln"?

Zitat:

Was aber, wenn die oberen darauf reagieren müssen, wenn auf den unteren Schichten was passiert? Dafür gibt es Indirektionsmechanismen. Also Events oder beispielsweise das Observer-Pattern.

Das klingt strukturell sehr sinnvoll. Ich werde das mal über ein Event ankoppeln. Der Grundsatz, dass alle sichbaren Komponenten ungültig und bei Gelegenheit neu gezeichnet werden, bleibt ja aber dadurch gleich...

Zitat:

Ganz böse. Du hast hier eine Abhängigkeit erzeugt, die dir sehr lustige Probleme bereiten kann.

Das Problem ist der Focus und ein Selectionsrahmen, der von meinen Items gezeichnet wird. Verliert ein zu entfernendes Item den Focus (dadurch, dass sich in der übergeordneten Liste etwas ändert) zeichnet es sich sofort neu. Wenn dann die DC oder deren XmlKnoten (bzw. die Zeiger darauf) ungültig, da gelöscht sind, dann kann es beim Zeichen knallen, da die Kompo nochmal auis dem gelöschten Knoten lesen will.
Daher suche ich im DC.Destroy alle Zeiger auf diese und setze sie auf nil. Das funktioniert, sofern ich weiß, wo diese Verweise vokommen können.

Zitat:

Jein. Du löst das Problem nicht, du umgehst es.

Hmm, wie ginge es besser?


@ Uli
Das habe ich mir schon angesehen, aber das schien nicht zu passen. Wenn ich das richtig verstanden habe funktioniert das Konzept nur in Zusammenhang mit Listen.
(Ich habe aber dann irgendwann aufgegeben :shock:)

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1047910)

Zitat:

Das könnte man entkoppeln, was etwas schöner wäre. Aber auch das ist noch OK. Kann man so machen.

Wie meinst Du "entkoppeln"?

Eigentlich muss eine Klasse, die Spieler oder Mannschaften verwaltet, gar nicht wissen, dass diese in XML-dateien gespeichert werden. Das kann in ne separate Klasse. Dadurch kannst du das Dateiformat leicht ändern, die Daten auch mal in ne Datenbank schreiben u.ä. ==> Die Datenpersistenz ist von der Datenrepräsentation entkoppelt. Lose Lopplungen machen ein Programm also flexibler, deshalb versucht man meist eine möglichst lose Kopplung zu erreichen.

Zitat:

Zitat:

Was aber, wenn die oberen darauf reagieren müssen, wenn auf den unteren Schichten was passiert? Dafür gibt es Indirektionsmechanismen. Also Events oder beispielsweise das Observer-Pattern.

Das klingt strukturell sehr sinnvoll. Ich werde das mal über ein Event ankoppeln. Der Grundsatz, dass alle sichbaren Komponenten ungültig und bei Gelegenheit neu gezeichnet werden, bleibt ja aber dadurch gleich...

Jein. Das sollte unabhängig vom Neuzeichnen sein. Die Komponenten zeichnen sich neu, wenn das nötig ist. Punkt. Zweitens kann es sein, dass sich die Darzustellenden Daten geändert haben. Das bemerkst du über n Event, liest die neuen Daten ein und rufst dann Invalidate auf. Das Einlesen der neuen daten, erstellen und Löschen von Objekten, etc. geschrieht aber in diesem Event. In OnPaint hat das nix verloren. Das ist das Problem. In OnPaint gehört nur Zeichencode. Nix anderes.

Zitat:

Daher suche ich im DC.Destroy alle Zeiger auf diese und setze sie auf nil. Das funktioniert, sofern ich weiß, wo diese Verweise vokommen können.

Zwischen "funktioniert" und "ist gut" ist aber noch ein Unterschied...

Zitat:

Zitat:

Jein. Du löst das Problem nicht, du umgehst es.

Hmm, wie ginge es besser?

Siehe oben. In OnPaint gehört nur Zeichencode. Wenn du das beherzigst, hast du die Probleme nicht.

mfg

Christian

[stahli]

Zitat:

Eigentlich muss eine Klasse, die Spieler oder Mannschaften verwaltet, gar nicht wissen, dass diese in XML-dateien gespeichert werden.

Ja, das habe ich schon so gelöst (hatte die Beschreibung etwas vereinfacht). Die Methoden der DC´s greifen halt über Read- und Write-Funktionen auf XML-Knoten zu.

Zitat:

In OnPaint gehört nur Zeichencode.

Ok, ich she aber noch keine bessere Lösung. In den Daten gibt es irgendeine Änderung. Die sichbaren Controls werden darüber informiert. Wenn sie gerade unsichtbar oder in einem ausgeblendeten Formular oder register sind, ist denen die Änderung egal.
Selektiert der Nutzer aber nun das übergeordnete Register oder blendet das übergeordnete Formular wieder ein, müssen sich die Controls ja mit den aktuellen Daten zeichnen...
Daher aktualisiere ich

Delphi-Quellcode:

Text := NeuerWertAusDatenbank

einfach, bevor sich die Komponente zeichnet.
Eine wirklich bessere Lösung fällt mir nicht ein, außer alle benötigten Daten direkt bei der Änderungsnachricht abzurufen und in Variablen abzulegen. Dann kann Paint diese hinterlegten Werte beim nächsten Zeichnen benutzen.
Die 3 Problem dabei sind m.E.:
1) dass alle zig000 Komponenten ständig die Daten abfragen, obwohl sie überhaupt nicht angezeigt werden
2) für alle "Felder" private Variablen zum Zwischenspeichern angelegt werden müssen (doppelte Datenhaltung)
3) Für einige Komponentendarstellungen teilw. recht komplexe Datenermittlungen (Funktionen, Suchen, Berechnungen) möglich sein können. Das wäre unnötig, wenn die Komponente ja gar nicht angezeigt wird.

Deshalb kam ich auf meine Lösung...

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1047982)

Zitat:

Eigentlich muss eine Klasse, die Spieler oder Mannschaften verwaltet, gar nicht wissen, dass diese in XML-dateien gespeichert werden.

Ja, das habe ich schon so gelöst (hatte die Beschreibung etwas vereinfacht). Die Methoden der DC´s greifen halt über Read- und Write-Funktionen auf XML-Knoten zu.

Nein, hast du nicht. Allein schon die Tatsache, dass deine Klassen das XMl-Zeug benutzen, koppelt sie an XML. Stell dir vor du willst jetzt statt XML die Daten in ne Datenbank schreiben. Oder in nem Textformat speichern. Oder übers Netzwerk schicken. Entkoppelt wäre es, wenn du dazu die Klassen nicht anfassen musst. Dazu werden die Klassen entweder von außen benutzt, d.h. die Daten extern gelesen (nicht so schön [1]) oder aber das Speichern wird über DependencyInjection gemacht (schön). Das sähe dann in etwa folgendermaßen aus:

Delphi-Quellcode:

// Pseudocode
TFoo = class
private
  FMyWriter: TSomeWriter;
public
  property MyWriter read FMyWriter write FMyWriter;
  procedure Save();
  begin
    FMyWriter.Write(...);
    ...
  end;
end;

TSomeWriter = class
  procedure Write(); virtual; abstract;
end;

TXMLWriter = class(TSomeWrite)
  ...
end;

TDatabaseWriter = class(TSomeWrite)
  ...
end;

... grob skizziert ...

In TFoo steht rein gar nichts von XMl. Man kann allein durch ersetzen der MyWriter-Eingeschaft aus nem Speichern in XML eins in ne Datenbank machen. *Das* sind entkoppelte Objekte!

Zitat:

Zitat:

In OnPaint gehört nur Zeichencode.

Ok, ich she aber noch keine bessere Lösung. In den Daten gibt es irgendeine Änderung. Die sichbaren Controls werden darüber informiert. Wenn sie gerade unsichtbar oder in einem ausgeblendeten Formular oder register sind, ist denen die Änderung egal.

Das ist aber eine Optimierung von dir. Und die bringt dich in Teufels Küche. Soll ich nochmal Knuth zitieren? Klar verschenkt es Rechenzeit, wenn du alles aktualisierst und nicht nur das, was angezeigt wird. Allerdings sollte das normalerweise im vernachlässigbaren Bereich sein.

Was du hier aber machst, ist, inkonsistente Zustände erlauben. Eben die unsichtbaren Komponenten, die nicht aktualisiert werden. Sowas sollte man nur tun, wenn man *ganz* genau weiß, was man tut und einen guten Grund dazu hat.

Zitat:

Eine wirklich bessere Lösung fällt mir nicht ein, außer alle benötigten Daten direkt bei der Änderungsnachricht abzurufen und in Variablen abzulegen.

Nein, da verwechselst du was. Oder ich versteh dein Problem nicht ganz. Du musst da nix cachen. Es gibt zwei unterschiedliche Arten von Änderungen:
a) das Hinzufügen und Entfernen von Elementen ==> Diese Änderungen sollten direkt über ein Event in der GUI mitgezogen werden. Sodass immer und unter jeden Umständen gilt, dass es keine überzähligen und keine Fehlenden GUI-Elemente gibt.
b) das Ändern von irgendwelchen Werten. Die Werte können selbstverständlich in OnPaint gelesen werden. Das ist vollkommen unproblematisch. Nur solltest du in OnPaint niemals Konstruktoraufrufe oder ein "Free;" stehen haben.

Zitat:

1) dass alle zig000 Komponenten ständig die Daten abfragen, obwohl sie überhaupt nicht angezeigt werden

- Hast du wirklich Tausende von Objekten oder war das nur Übertreibung?
- Du musst selbstverständlich nicht die ganzen Wertänderungen nachziehen. Nur das Erzeugen und Freigeben von Listenelementen.

Zitat:

2) für alle "Felder" private Variablen zum Zwischenspeichern angelegt werden müssen (doppelte Datenhaltung)

Ein Caching kann aus Performancegründen zwar manchmal gut sein. Hier wäre es aber eher kontraproduktiv.

Zitat:

3) Für einige Komponentendarstellungen teilw. recht komplexe Datenermittlungen (Funktionen, Suchen, Berechnungen) möglich sein können. Das wäre unnötig, wenn die Komponente ja gar nicht angezeigt wird.

Es geht - wie schon erläutert - nicht um die Darstellung. Die kann und soll in OnPaint gemacht werden. Also nur dann, wenn auch wirklich gezeichnet wird.


[1] Weil das Objekt ja eigentlich selbst zu wissen hat, was von ihm gespeichert gehört. Man kann das auch mit Annotationen - oder wie heißen die Dinger in Delphi? Attribute glaub ich - festlegen und so generisch speichern. Dann ist gegen den externen zugriff wiederum nichts zu sagen.

mfg

Christian

[stahli]

Ok, wir nähern uns an :-)
Also über die reine Wertaktualisierung brauchen wir nicht mehr reden.

Die Anzahl von Einträgen (Datensätzen, Items) können auch mal aus der Datenschicht heraus geändert werden, also eben nicht durch die GUI angestoßen sein.
Oder ich schließe ein SubFormular mit einer Liste von 10 Items (das letzte hat den Fokus). Dann gibt es irgendwelche Änderungen und das SubForm wird wieder geöffnet - jetzt gibt es noch 5 Einträge.
Bevor ich die überzähligen Items entfernen kann, zeichnet Windows (wegen dessen Focus) schon das letzte Item (ist von einen Panel abgeleitet).

Ok, ich habe Dich aber verstanden und werde das mit berücksichtigen.

Danke für die Hilfe!

[r2c2]

Zitat:

Zitat von stahli (Beitrag 1048101)

Ok, wir nähern uns an :-)

schön. :-)

Zitat:

Die Anzahl von Einträgen (Datensätzen, Items) können auch mal aus der Datenschicht heraus geändert werden, also eben nicht durch die GUI angestoßen sein.

Deshalb die Events.

Zitat:

Oder ich schließe ein SubFormular mit einer Liste von 10 Items (das letzte hat den Fokus). Dann gibt es irgendwelche Änderungen und das SubForm wird wieder geöffnet - jetzt gibt es noch 5 Einträge.
Bevor ich die überzähligen Items entfernen kann, zeichnet Windows (wegen dessen Focus) schon das letzte Item (ist von einen Panel abgeleitet).

Deshalb wichtig: Keine inkonsistenten Zustände erlauben. Also am besten das Fenster beim Schließen freigeben und beim Öffnen neu erzeugen. Wenn du das aus irgendwelchen Gründen nicht tun willst, aktualisiere eben auch dieses - geschlossene - Fenster. Wenn auch das zu viel ist, dann bemüh OnShow. Aber auf keinen Fall OnPaint.

mfg

Christian

[stahli]

Ok danke, ich werde versuchen, mich zu bessern! :)

... ach so ...

Der Vorteil meiner Lösung ist jedoch, dass man sich dann im Projekt um solchen Kram wie Freigabe im Formular.OnClose oder Aktualisierungen im Formular.OnShow nicht mehr kümmern muss. Die Kompos machen das halt dann alles selbständig.

Solange das zuverlässig funktioniert, hat das sicher auch etwas für sich ;-)

Mal sehen, ich schlafe nochmal drüber...