Komponente mit Objekten, die Eigenschaften der Komponente benötigen

[Bjoerk]

Tell me about it... Diese Lösung hat doch gerade den Vorteil daß die Liste NICHT geändert werden muß?

[Dejan Vu]

Zitat von Bjoerk:

Tell me about it... Diese Lösung hat doch gerade den Vorteil daß die Liste NICHT geändert werden muß?

Auf Deutsch or in English? Blyben weer bay deutsh. This can I besser.

Zitat von Bjoerk:

TUrlaub, TKrank, TLehrgang usw. sind davon abgeleitet und überschreiben diese Methoden.

Ich lese daraus, das Du die Klassen *im Code* ableitest. Wie willst Du dann zur Laufzeit "TBetriebsausflug" und "TGrillabend" oder "TSauseOhneDenChef" anlegen?

Diese Klasse hat eh nur eine Paint-Methode und unterscheidet sich nur in der Wahl der Hintergrundfarbe und -textur sowie Textausprägung und -farbe. Vielleicht noch Sparkling-Effekte o.ä., aber das ist eine einzige banale Klasse. Über die editierbaren Eigenschaften steuerst Du das Aussehen.

[Bjoerk]

Zitat von Dejan Vu:

[..] This can I besser.

Jo, das Gefühl hab ich auch..

BTW, mein Vorschlag war eher an den TE gerichtet und weniger an dich mit der Bitte um Stellungnahme..

[Captnemo]

Danke für die vielen Antworten.

Nur so am Rande: Das ich mir mal eine Komponente selber geschrieben habe ist Jahre her. Sprich, zur Zeit fang ich da bei Null an.

Zurück zum Thema.

Okay. Zu TLayoutTemplate oder zu Template Manager spuckt meine Hilfe so gar nichts aus. Kann mir das jemand noch mal erläutern.

Zur Darstellung:

Code:

  TEintragsTypListe (TObjectList)   <--------------------------+
   |                                                          |
   +-->TEintragsTyp (TObject)                                  |
   |    |                                                     | 
   |    +-->Bezeichnung: string;                               |
   |    +-->Farbe: TColor;                                     |
   |    +-->...                                                | (Oder nur ein TObject,
   +-->Count: Integer;                                         |  dass dann auf den
                                                              |  TEintragstyp zeigt)
  TEintragListe  (TObjectList)                                  |
   |                                                          |
   +-->TEintrag  (TObject)                                      |
   |    |                                                     |
   |    +-->Text: string;                                      |
   |    +-->TEintragsTypListe (TObjectList)    Zeigt auf ------+
   |    +-->EintragsTypIndex: Integer;
   +-->Count: Integer

  TUrlaubskalender (TObjectList)
   |
   +-->Eintragstypen: TEintragsTypList
   +-->Eintraege: TEintragListe
   +-->...noch ein paar globale

So hätte ich es mir vorgestellt. Das zur Laufzeit halt Eintragstypen hinzugefügt werden können.

Wenn dann aber Einträge hinzugefügt werden, muß ja irgendwie im Eintrag ein Zeiger auf die Eintragstypenliste mitgegeben werden. Das könnte man zwar auch über das OnCreate machen, sieht für mich aber ein irgendwie unschön aus.
Meine Frage zielt also darauf ab, wie man so was am elegantesten macht.

Mir fällt da grad noch einen andere Frage zu ein:
Wenn ich z.B. ein Eintrag hinzufüge, möchte ich gerne, dass die Komponente seine Paint-Routine aufruft. Da Eintrag ja eine eigene Klasse ist, kann sie ja nicht von welcher Klasse sie erzeugt ist. Oder doch?

[himitsu]

Und genau für sowas sind doch die Collections da.
> Eine Liste von eigenen Klassen eines Typs.

Man kann das natürlich auch alles selber machen, z.B. über Objektlisten, aber wenn man das auch noch über den OI bedienen will, würde man dann noch anfangen sich einen passenden Property-Editor zu schreiben, welcher mit dieser Liste und den enthaltenen Klassen umgehen kann.

[stahli]

Die wichtigsten Fragen sind aus meiner Sicht (immer) noch offen...

Wozu eigentlich eine Komponente?
Die brauchst Du ja eigentlich nur, wenn Du eine universelle Einsetzbarkeit benötigst oder wenn Du die Einträge zur Designtime eintragen willst.

Willst Du die Komponente dann zur Designtime konfigurieren (mögliche Eintragstypen einrichten) oder soll das der Enduser nach Bedarf machen dürfen.
Das hier

Zitat:

Das zur Laufzeit halt Eintragstypen hinzugefügt werden können.

würde das letztere nahelegen.

Also bringt es Dir nichts, n feste Klassen zu definieren (zu kompilieren), da der Enduser dann ja nicht weitere Klassen hinzufügen kann.
In dem Fall brauchst Du keine Komponente oder jedenfalls keine, die zur Designtime über eine Collection konfiguriert wird.
Collection vereinfachen gegenüber Objektlisten das Speichern und Bearbeiten von Einträgen in der IDE.
Wenn man diese Funktionalität nicht braucht, sollte man m.E. auch keine Collections verwenden.

Für mich klingt das eher nach einer Anwendung mit einer relationalen Datenbank und passenden Tabellen.

Natürlich kann man die Daten und Beziehungen auch in Objekten ablegen, dann muss man halt ID´s definieren, wenn Beziehungen nach dem Speichern und erneutem Öffnen wieder hergestellt werden müssen.

[Captnemo]

Zitat von stahli:

Wozu eigentlich eine Komponente?

Natürlich ginge das auch ohne Komponente.
Aber da ich sowas noch nie so richtig gemacht habe, wollte ich mich mal damit beschäftigen. Kann ja nicht schaden.

Und auch wenn sich dann manche Dinge etwas aufwendiger gestalten, als wenn man das ohne Komponente realisieren würde, will ich es trotzdem versuchen.

Zwar werden die Einträge und die Eintragstypen später sicherlich aus eine DB bestückt, so möchte ich trotzdem auch zur DT im IO auch welche hinzufügen können, die dann auch zur DT in der Komponente sichtbar sind. Auch wenn man es nicht zwangsläufig braucht. Ist halt gleichzeitig ein Übungsprojekt.