Component.Free -> auch fremde Zeiger auflösen

[Uwe Raabe]

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

[r2c2]

Zitat von Uwe Raabe:

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.
DC.Free sollte für alle existierenden SC, bei denen SC.DC = freigegebeneDC ist
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 von stahli:

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.
DC.Free sollte für alle existierenden SC, bei denen SC.DC = freigegebeneDC ist
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 von stahli:

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!