Danke für das ausführliche Statement...
Zitat:
Zitat:
Es gibt ja auch Gemeinsamkeiten die ich nicht im Vorfahr ablegen kann.
Die da wären? Da versteh ich nicht so ganz, was dein Problem ist. Leider ist das wohl die zentrale Stelle...
...die Button Events der Form werden als Event weitergereicht. Somit bräuchte jede abgeleitete Klasse die entsprechenden Prozeduren.
Zitat:
Zitat:
Dann nur je nach Status (OK / Abbruch) die Daten über die ObjectList holen oder verwerfen.
Da versteh ich nicht, wo auf einmal die ObjectList herkommt.
...die Objectlist wo die Controls drinstehen. Je Editor eine eigene.
Zitat:
Zitat:
1. Möglichkeit:
- für jeden Objekttyp eine Klasse
2. Möglichkeit:
- eine Klasse
- anhand des Objekttypes entscheiden welche Controls erstellt werden (ObjectList)
Kommt drauf an. Dazu müsste man wissen, wie stark sich die Objekttypen unterscheiden. Je stärker, desto eher getrennte Klassen.
... ich habe mich für getrennte Klassen entschieden wobei ich noch eine "dazwischengeschaltet" habe
TKlasse1: TForm
TKlasse2: TKlasse1 // Event entgegennehmen, Liste Controls erzeugen/ freigeben ... Gemeinsamkeiten
TKlasseEditorObject: TKlasse2 //managed die benötigten Controls und die Anzeige
Zitat:
Zitat:
es sind auch Controls vom Typ Combobox enthalten. Wenn man das Objekt selbst "entscheiden" lassen würde müßte man auch dem Editor mitteilen wo er die Daten herbekommt. Das ist eher nicht optimal oder ?
Da weiß ich gar nicht, was du meinst.
...die Comboboxen müssen dynamisch mit
DB Daten gefüllt werden. Entweder von außen oder der Editor kennt das "
DB Framework" um sich die Liste der Daten selbst zu holen. Wäre nicht das Problem ihm das über eine Property bekannt zu machen.
