Komponente mit Objekten, die Eigenschaften der Komponente benötigen

[Captnemo]

Zitat von Dejan Vu:

(*) Aus diesem Grund mag ich auch keine TCollection.

Hab grad auf TCollection umgestellt Und dann kann ich auch im OI zur DT Items hinzufügen. Als ich es noch über TObjectList gemacht hatte, ging das nicht.

Jetzt hab ich das auch besser verstanden.

Zitat von Dejan Vu:

Dafür gibt es eine Klasse, die diese Templates verwaltet (TemplateManager). Die Klasse hat eine Methode

Delphi-Quellcode:

//
Function Template(aTemplateType : TTemplateType) : TLayoutTemplate;
//

Der Urlaubsplan instantiiert einen TemplateManager. Im OI kannst Du die Farben für die einzelnen Eintragstypen (TTemplateType) dann konfigurieren.

Dieser Satz hat mich zu der Annahme geführt, dass es eine vordefiniert Klasse TLayoutTemplate o.ä. gibt.

Beim TEintrag.Create die Typenliste mit zu übergeben hatte ich mir auch schon so vorgestellt. Werde ich gleich mal ausprobieren. Mal sehen wie weit ich komme.

Aber es stellt sich mir noch ein anderen Problem: Das Neuzeichnen wenn Einträge hinzugefügt werden.
Als Beispiel nehme ich mal ein TListView. Wenn ich im OI Columns oder Items hinzufüge, dann wird das sofort im ListView umgesetzt und dargestellt.
So würde ich das auch gerne machen.
Aber wie erfährt meine Basisklasse, dann ist der Klasse TEinträge ein Eintrag hinzugefügt wurde? Ich hab schon überlegt das über eine Windows-Message zu machen, aber da meine Basisklasse von TGraphicControl abgeleitet ist, hat sie kein Handle.

[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.

[Dejan Vu]

Zitat von Captnemo:

Aber es stellt sich mir noch ein anderen Problem: Das Neuzeichnen wenn Einträge hinzugefügt werden.
Als Beispiel nehme ich mal ein TListView. Wenn ich im OI Columns oder Items hinzufüge, dann wird das sofort im ListView umgesetzt und dargestellt.
So würde ich das auch gerne machen.

Mach es doch. Der TEintrag hat ein Event 'OnChange'. Das ruft ein Eintrag auf, wenn sich irgendwas in ihm verändert hat. Und dein TUrlaubsplan 'subscribed' sich auf dieses Event. Einfach ausgedrückt: Im 'AddEintrag' setzt Du das Event.

Delphi-Quellcode:

Procedure TUrlaubsPlan.ItemChanged (Sender : TObject);
Begin
  Assert (Sender is TEintrag, 'Nee, Du darfst diesen Handler nur an TEintrag-Instanzen bepseln');
  Repaint....
End;

Procedure TUrlaubsPlan.AddEntry (...);
Var
  derNeueEntrag : TEintrag;

begin
  ...
  derNeueEintrag.OnChanged := ItemChangeD;
  ...
End;

[stahli]

@Captnemo

Ich war überrascht, dass Du Dein Projekt mal in 2 Stunden auf Collections umgestellt hast. Insofern gehe ich (ich will nicht nerven!) immer noch davon aus, dass Du etwas auf dem Holzweg bist.

Collections haben eigentlich nur Nachteile - AUßER wenn es um die Bearbeitung der Einträge über einen Komponenteneditor und vor allem um das Speichern der Einträge in der dfm geht.
Das geht mit Collections einfacher (oder nahezu NUR mit Collections). Alles andere geht besser mit normalen Listen.

Die Einträge der Collections werden in der dfm ungefähr so gespeichert:
Meine Liste
- Eintrag (Vorname, Nachname, Alter)
- Eintrag (Vorname, Nachname, Alter)
- Eintrag (Vorname, Nachname, Alter)
- Eintrag (Vorname, Nachname, Alter)

Beim Laden des Formulars werden diese Einträge dann wieder hergestellt. Aber Du kannst nicht so einfach Beziehungen zwischen den Einträgen oder auf bestimmte Einträöge abbilden.

Ein schönes Beispiel sind Columns. Da steht im Grid, welche Spalten dargestellt werden sollen und wie die beschriftet werden sollen. Es gibt aber nicht die Möglichkeit, über einen Componentennamen (wie Edit1 oder Panel500) auf die 3. Spaltendefinition zuzugreifen.

Ich für mich habe die Einträge gedanklich eher als Records angesehen, wobei das streng genommen natürlich nicht richtig ist. Die Handhabung ist aber ähnlich.

Wenn Du nun Deine Geschäftsdaten ("Eintragsarten" - ich benutze mal nicht "Typen", weil es ja hier nicht um Typen oder Klassen für den Compilers geht) dort ablegen willst macht das eigentlich nur Probleme.
Aus meiner Sicht gehören dort nur Strukturanweisungen für die GUI hinein (eben z.B. die Spaltendeklarationen für ein Grid).

Wenn Du willst, dann schau mal auf mein Video zu meinem Framework: http://www.youtube.com/watch?v=HBq9e...ature=youtu.be (Komponenteneditor ab Min. 12)
Da ich die Eintragsbearbeitung dort mit meinem Databinding durchführen wollte habe ich die CollectionItems in eine normle Liste übertragen und nach der Bearbeitung wieder zurück.

Wenn der Komponentenexperte geschlossen wird gibt es aber keinen Bezug mehr zwischen der alten und neuen Collection. Wenn man dies braucht muss man den Items eine eigene ID zuweisen und kann so prüfen, welche Einträge neu sind oder geändert wurden.

Also: Der Umgang mit Collections ist umständlich und nur sinnvoll, wenn man zur Designtime einen Komponenteneditor nutzt und die Einträge in der dfm speichern will.

Ich habe natürlich nichts degen, dass Du Collections nutzt oder testest aber ich glaube, Dein Anwendungsfall ist nicht der richtige dafür...
Hast Du denn einen Komponenteditor für Deine Items?

Wenn ja und wenn Du das dann mal mit Geschäftsdaten-Datei kombinieren willst dann müssten Deine Items irgendeine eindeutige ID erhalten, damit Du die irgendwie weiterverarbeiten kannst.