Komponente mit Objekten, die Eigenschaften der Komponente benötigen

[himitsu]

Aus welchem Grund?
Das TCollectionItem kennt doch nicht die übergeordnete TCollection. (leider)

Und ich weiß auch nicht, warum es schlecht sein soll, seine Eltern zu kennen.

[DeddyH]

Wenn ich es richtig verstehe, ist dafür die Methode TCollection.Notify gedacht.

[himitsu]

Damit kann nur die Collection drauf reagieren, wenn etwas in ihr geändert wird.
Die CollectionsItems haben kein Notify.

Standardmäßig wissen die Items nicht ob und in welcher Collection sie sich befinden,
außer man würde sich selber ein Owner/Parent-Feld in die Items einbauen und dann z.B. im Notify diese Variable setzen.



Hatte mal versucht das als generische Objektvorlage umzusetzen, was bei eigenen Deklarationen geht, aber nicht wenn man von den Originaltypen erbt, also wo dann die Collections und Items sich gegenseitig kennen und auch noch die Typen/Property/Parameter richtig gecastet sind.
Zwei getrennte Typen ableiten und sich gegenseitig referenzieren zu lassen war mit den Generics aber nicht so leicht möglich, vorallem wenn man sie in der VCL und speziell im FormDesigner und ObjektInspektor haben möchte, wo man dann noch das generische < und > im Namen verstecken muß.

[DeddyH]

Wozu brauchen denn die Items ein Notify? Die Collection gibt bei Änderungen Bescheid und benennt dabei das Item und die Art der Änderung. Darauf kann man reagieren und z.B. neu zeichnen.

[Captnemo]

Zitat:

Zitat von himitsu (Beitrag 1273091)

Aus welchem Grund?
Das TCollectionItem kennt doch nicht die übergeordnete TCollection. (leider)

Und ich weiß auch nicht, warum es schlecht sein soll, seine Eltern zu kennen.

Ja, das Item kennt seine Liste, aber kennt die TCollection die Klasse, in der sie existiert?

Es sieht bei mir zur Zeit so aus:

Delphi-Quellcode:

unit tuUrlaubskalender;

  TUrlabuskalender = class
    Property TEintraege: TEintraege;
    property TEintrastypen: TEintragstypen;
    propcedure Paint;
  end;

----

unit tuEintraege;

  TEintraege = class(TCollection)
    ...
  end;
  

  TEintrag = class(TCollectionItem)
    ...
  end;

---

unit tuEintragstypen;

  TEintragstypen = class(TCollection)
    ...
  end;

  TEintragstyp = class(TCollectionItem)
    ...
  end;

Wenn jetzt z.B. TUrlaubskalender.Eintraege.Add aufgerufen wird, wie bekommt denn die Klasse TUrlaubskalender das mit, denn hier existiert die Methode Paint.

[Captnemo]

Gut ich könnte in der TUrlaubskalender eine Methode AddEintrag machen, die ihrerseits dann die Add-Mothode der Collection Eintraege aufruft.
Aber macht man das so? Oder gibt es noch den weg rückwärts über irgendeine Benachrichtigung.

[himitsu]

Indem die Collections deine Komponente kennen. Mußt du einbauen, indem du das Notify überschreibst und dort deinem Kalender sagst "du, da hat sich was geändert ... mach ma".

[Captnemo]

Meinst du so:

Delphi-Quellcode:

Constructor TUrlaubsplan.Create;
begin
  inherited;
  self.FEintraege:=TEintraege.Create(self);
end;


//Und im TEitraege

...
  FParent: TURlaubsplan;
.
.
.
constructor TEintreage.Create(Urlaubsplan: TUrlaubsplan);
begin
  inherited;
  self.FParent:=Urlaubsplan;
end;

dann könnte ich ja im TEintraege.Notify ja self.FParent.Paint aufrufen, oder?

[Captnemo]

Zitat:

Zitat von Captnemo (Beitrag 1273115)

Meinst du so:

Delphi-Quellcode:

Constructor TUrlaubsplan.Create;
begin
  inherited;
  self.FEintraege:=TEintraege.Create(self);
end;


//Und im TEitraege

...
  FParent: TURlaubsplan;
.
.
.
constructor TEintreage.Create(Urlaubsplan: TUrlaubsplan);
begin
  inherited;
  self.FParent:=Urlaubsplan;
end;

dann könnte ich ja im TEintraege.Notify ja self.FParent.Paint aufrufen, oder?

Geht so leider nicht, dann bekomme ich "F2047: Zirkuläre Unit-Referenz" vom Compiler, weil ich ja in beiden Unit die jeweilig andere referenzieren muss.

[DeddyH]

Wieso kein Event? Dann kann der Urlaubsplan dem einen Handler zuweisen, die Einträge müssen den Urlaubsplan aber gar nicht kennen, sondern führen nur den ggf. zugewiesenen Code aus.