Erweitern einer vorahandenen Property in einer VCL Komponente

[sko1]

TMyWebOsMaps aus TWebOsMaps ableiten und da die neue Property einbauen?

Ciao
Stefan

[himitsu]

Erstmal nachschauen welche Klasse die einzelnen Marker haben.
Diese Klasse ableiten und um dein Property erweitern.

Dann die Stelle suchen, wo die Instanzen jener Marker-Klasse erstellt werden und ob/wie man da diese Klasse durch deine Ableitung ersetzt.

Und das bis hoch zur TWebOsMaps, falls es mehrere Ebenen gibt, wie z.B.:
* Marker-Klasse ableiten
* Marker-Liste ableiten, zum Reinhängen der Marker-Klasse
* TWebOsMaps ableiten, zum Ersetzen der Marker-Listen-Klasse.

Am Besten macht es sich, wenn TMS dafür in den übergeordneten Klassen die nötigen Funktionen als virtual deklariert hat und das möglichst fein diffenenziert, z.B. ala CreateMarker oder GetMarkerClass, bzw. wenn die Liste ihre Item-Klasse im Contructor bekommt, ala TCollection.Create.



"Umständlicher" :
Du führst eine Liste/Array mit den GUIDs und schreibst bei den Klassen in .Tag den jeweiligen Index.

Oder andersrum, über die Instanzen verlinkt. -> TDictionary<TMarker, TGUID>

[Uwe Raabe]

Zitat von himitsu:

Erstmal nachschauen welche Klasse die einzelnen Marker haben.
Diese Klasse ableiten und um dein Property erweitern.

Dann die Stelle suchen, wo die Instanzen jener Marker-Klasse erstellt werden und ob/wie man da diese Klasse durch deine Ableitung ersetzt.

Und das bis hoch zur TWebOsMaps, falls es mehrere Ebenen gibt, wie z.B.:
* Marker-Klasse ableiten
* Marker-Liste ableiten, zum Reinhängen der Marker-Klasse
* TWebOsMaps ableiten, zum Ersetzen der Marker-Listen-Klasse.

Am Besten macht es sich, wenn TMS dafür in den übergeordneten Klassen die nötigen Funktionen als virtual deklariert hat und das möglichst fein diffenenziert, z.B. ala CreateMarker oder GetMarkerClass, bzw. wenn die Liste ihre Item-Klasse im Contructor bekommt, ala TCollection.Create.

Die aktuelle Implementierung lässt diesen Weg leider nicht zu. Man muss die Collection von TMarkers ableiten, hat aber dann keinen Einfluss mehr auf die ItemClass. Das Design ist in diesem Punkt alles andere als flexibel.

Zitat von himitsu:

"Umständlicher" :
Du führst eine Liste/Array mit den GUIDs und schreibst bei den Klassen in .Tag den jeweiligen Index.

Oder andersrum, über die Instanzen verlinkt. -> TDictionary<TMarker, TGUID>

Ist in diesem Fall wohl der einzig gangbare Weg.

[mensch72]

Per "Tag" über ein Dictionary auf XY zukommen geht ja auch... aber die TMS Sourcen sind doch gut lesbar und strukturelles "Copy&Paste", das Konzept mit/über Collections ist da doch egal um was es grade geht immer gleich...

Du hast doch die Marker-Klasse nun eh schon gefunden, haue da einfach den von dir benötigten Wert unter Public als dirkte Membervariable ohne Getter/Setter hinein... mit jedem anständigem Merge/Diff-Tool bekommste solche "Einzeiler" ohne jegliche Abhängigkeit nachträglich bei TMS Updates ganz simpel nachgetragen. Nicht die feine Art, aber in diesem Fall wohl der effektivste Weg

[fisipjm]

Zitat von mensch72:

Du hast doch die Marker-Klasse nun eh schon gefunden, haue da einfach den von dir benötigten Wert unter Public als dirkte Membervariable ohne Getter/Setter hinein... mit jedem anständigem Merge/Diff-Tool bekommste solche "Einzeiler" ohne jegliche Abhängigkeit nachträglich bei TMS Updates ganz simpel nachgetragen. Nicht die feine Art, aber in diesem Fall wohl der effektivste Weg

Ich glaub ich Versteh dich nicht ganz
Was meinst du mit ich hab die Marker-Klasse gefunden? Ich kann sie Aufrufen und zur Not auch mit einer eigenen Klasse ableiten, aber ich hab keinen Zugriff auf die Klassen deklaration. Hast du vielleicht ein "Einzeiler" Dummy Code, vielleicht kann ichs mir dann besser vorstellen.

Danke für die Antwort.

[fisipjm]

Zitat von Uwe Raabe:

Zitat von himitsu:

"Umständlicher" :
Du führst eine Liste/Array mit den GUIDs und schreibst bei den Klassen in .Tag den jeweiligen Index.

Oder andersrum, über die Instanzen verlinkt. -> TDictionary<TMarker, TGUID>

Ist in diesem Fall wohl der einzig gangbare Weg.

Ich habs befürchtet, den Wert ID hat der Marker ja, den kann man dafür verwenden um ihn später auch wieder anzusprechen. Ich wollte das aber eigentlich lieber umgehen, da es der ohnehin schon recht umständlichen Programmierung noch einen weiteren Step hinzufügt

Danke für die Antwort

[himitsu]

Zitat von fisipjm:

Ich habs befürchtet, den Wert ID hat der Marker ja, den kann man dafür verwenden um ihn später auch wieder anzusprechen. Ich wollte das aber eigentlich lieber umgehen, da es der ohnehin schon recht umständlichen Programmierung noch einen weiteren Step hinzufügt

Anzeigen und Speichern hängt aber nicht immer untrennbar zusammen.

Du kannst problemlos die GUIDs in einer externen Liste verwalten, aber die jeweilige GUID dennoch in deinen Marker-Items als Property bereitstellen.

Stichwort: Class-Helper
Also das Property nachträglich/virtuell an dem Marker hängend, aber im Getter/Setter dieses Property die GUID extern verwalten. (z.B. in dem Dictionary)

[fisipjm]

Zitat von himitsu:

Zitat von fisipjm:

Ich habs befürchtet, den Wert ID hat der Marker ja, den kann man dafür verwenden um ihn später auch wieder anzusprechen. Ich wollte das aber eigentlich lieber umgehen, da es der ohnehin schon recht umständlichen Programmierung noch einen weiteren Step hinzufügt

Anzeigen und Speichern hängt aber nicht immer untrennbar zusammen.

Du kannst problemlos die GUIDs in einer externen Liste verwalten, aber die jeweilige GUID dennoch in deinen Marker-Items als Property bereitstellen.

Stichwort: Class-Helper
Also das Property nachträglich/virtuell an dem Marker hängend, aber im Getter/Setter dieses Property die GUID extern verwalten. (z.B. in dem Dictionary)

Himitsu du bist offiziel der Held des Tages

Hab es jetzt folgendermaßen gelöst:

Delphi-Quellcode:

USES
..., Generics.Colletions,....

type
TMarkerHelper = class helper for TMarker
  class var
    AddressGGUIDDictionary : TDictionary<TMarker,String>;
  public
    procedure SetAddressGGUID(lAddressgguid : string);
    function GetAddressGGUID : string;
  published
    property AddressGGUID:string read GetAddressGGUID write SetAddressGGUID;
end;

.....

procedure tmarkerhelper.SetAddressGGUID(lAddressgguid: string);
begin
  if not assigned(AddressGGUIDDictionary) then
    AddressGGUIDDictionary:=TDictionary<TMarker, String>.Create;
  AddressGGUIDDictionary.Add(self,lAddressgguid);
end;

function tmarkerhelper.getAddressGGUID : string;
begin
  AddressGGUIDDictionary.TryGetValue(self,result);
end;
 
...

Habs getestet und macht was es soll. Gibts da noch was zu beachten oder passt der Code so?
MFG
PJM

[DeddyH]

Ich würde das Anlegen/Freigeben der Dictionary-Instanz in einen Klassenkonstruktor/Klassendestruktor verlegen. Wenn Du im Moment lesend darauf zugreifst, ohne vorher geschrieben zu haben, macht es Bumms.

[himitsu]

Zitat von fisipjm:

Habs getestet und macht was es soll. Gibts da noch was zu beachten oder passt der Code so?

Delphi-Quellcode:

function tmarkerhelper.getAddressGGUID : string;
begin
  AddressGGUIDDictionary.TryGetValue(self,result);
end;

Dein Rückgabewert ist nicht initialisiert. (eigentlich doch, da String ein Managed-Type ist, aber nicht in Bezug auf diese Function)
Sowas macht Spaß, wenn getAddressGGUID z.B. in einer For-Schleife aufgerufen wird.

Delphi-Quellcode:

if not AddressGGUIDDictionary.TryGetValue(self,result) then
  Result := '';

Du hast ein Speicherleck bei AddressGGUIDDictionary. Die Liste wird nicht freigegeben.
Ich weiß nicht ob Class-Constructor und Class-Destructor bei Class-Helpern möglich sind, aber es gibt ja noch Initialization und Finalization der Unit.

Wenn TMarker von TComponent abgeleitet ist, dann könnte man noch TComponent.FreeNotification verwenden, um automatisch die GUID zu löschen, wenn der TMarker freigegeben wird.
https://stackoverflow.com/questions/...has-been-freed