Komponente mit Objekten, die Eigenschaften der Komponente benötigen

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