Basisklasse und davon abgeleitet drei Standardklassen

[Apollonius]

Besonders interessant ist, dass Interface- und Klassen-Propertys ganz unterschiedlich gehandhabt werden. Bei Interface-Propertys z.B. erhält die eigentliche Kasse gar keine eigene Interface-VMT, bei Klassen-Propertys schon.

[Sidorion]

@jelly: natürlich musst Du die Methode bei einer Instanz rufen. Ich hab das T nur hingeschrieben, um zu zeigen, dass kein Cast oder Umweg über die implementierende Property notwendig ist.
Allerdings geht das nur, wenn Du eine Variable vom Typ TMyEdit hast. Ist die Variable vom Typ TEdit oder weiterer Vorgänger, musst Du erst auf das Interface casten (mit As) oder auf eine Variable vom Typ des Interfaces zuweisen (Achtung hier kommt es zu Ausnahmen wenn wirklich eine Instanz von TEdit angelegt wurde).

Ach ja: Interfaces bringen eine Referenzzählung mit (das macht schon IInterface bzw. TInterfacedObject). Willst Du diese Klassen dann benutzen, musst Du sie in eine Variable des Interfacetyps instanzieren oder in der Helperklasse die Referenzzählung unterdrücken. Steht auch irgendwo in der OH. Ansonsten wird die Inszanz gleich nach dem Konstruktoraufruf wieder weggeschmissen.
Beispiel:

Delphi-Quellcode:

Var
  iMyEdit: IMyInterface;
Begin
  iMyEdit:=TMyEdit.Create(..);
End;

[Kedariodakon]

Zitat von Sidorion:

Ich hab das T nur hingeschrieben, um zu zeigen, dass kein Cast oder Umweg über die implementierende Property notwendig ist.

Hmm also bei mir ist das sehr wohl der Fall, ich muss immer über das Property MyHelper zu MyWind, also "(aObj as TMyEdit ).MyHelper.MyWind", also "(aObj as TMyEdit ).MyWind" tut es bei mir nicht.. (Delphi 7)


Bye Christian

[Dax]

Is ja süß, man muss immer den Umweg über eine Interface-Variable gehen..

[Sidorion]

Nein. Es reicht ein Cast. (MyObj As IMyInterface).MyWnd.
Wie gesagt, wenn man mit Interfaces arbeitet sollte man sowieso Interfacevariablen nutzen. Ist sozusagen eine weitere Abstraktionsstufe. Bei Objektorientierung habe ich einen schwarzen Kasten (einer bestimmten Art), an dessen Henkeln ich runschraube. Mit Interfaces Interessiert mich nichtmal mehr der Kasten, sondern nur noch, dass er bestimmte Henkel hat, an denen ich rumschrauben kann.

Ein Interface ist jedenfalls das einzige Sprachkonstrukt in Delphi mit dem sowas geht. Mehrfachvererbung iss ja nicht.

[Dax]

Zitat von Sidorion:

Nein. Es reicht ein Cast. (MyObj As IMyInterface).MyWnd.

Dann muss sich das seit Delphi 6 geändert haben

[shmia]

Zitat:

Ich muss dynamisch verschiedene Controls erzeugen. Nehmen wir beispielsweise(!) TEdit, TCheckbox und TComboBox.
Alle diese drei Controls müssen mit einer zusätzlichen Funktionalität ausgestattet werden. Nennen wir diese Funktionalität 'Sag mir Deinen Startwert' (nur als Beispiel!).
So, alle diese Controls werden mit einem Startwert (Text, Checked, Text) belegt.
Dieser kann zur Laufzeit geändert werden.
Irgendwann sollen mir diese Controls auf Zuruf ihren Startwert mitteilen.

Um deine Gedanken mal in eine ganz andere Richtung zu lenken:
Warum müssen die zusätzlichen Properties so eng mit den Controls verkoppelt werden ?
Es gibt ja auch das Model-View-Controller Prinzip.
Angenommen dein Modell wäre eine elektronische Schaltung mit vielen Bauteilen.
Jedes Bauteil hat unterschiedliche Properties (Widerstand, Kapazität,...).
Der View muss dynamisch zur Laufzeit aufgebaut und mit Controls versehen werden.
Anstatt nun die Controls mit zusätzlichen Properties auszustatten, könnte man doch eher
den View als Objektmodell (TResistor, TWire, TDiode, ...) aufbauen und dort alle Properties unterbringen.
Im View gibt es nun eine Liste, in der vermerkt ist, welches Control an welches Bauteil angekoppelt ist.
==> alle Controls bleiben Standard sind aber an das Modell gekoppelt

[s-off]

Zitat von shmia:

StichwortModel-View-Controller

Ohje. Und wieder was Neues Ich bin ja einerseits wirklich dankbar für die vielen neuen Vorschläge, aber ehrlich gesagt bin ich gerade etwas überfordert, das Ganze zu sortieren. Sei mir nicht böse, shmia, aber ich kann mich damit erst später auseinandersetzen, wenn ich das mit den Interfaces verstanden habe - ansonsten komme ich aus dem Chaos gar nicht mehr hinaus

Also, ich habe nun mal eine Beispielanwendung, basierend auf Sidorions Posts geschrieben.
Habe mir dieses Mal auch ein etwas sinnvollerers Beispiel überlegt, damit das Ganze etwas anschaulicher wird.

Standardcontrols (Label, Edit etc.) sollen eine Zoommöglichkeit bekommen (das ist wieder nur ein Beispiel - bitte keine anderen Wege aufzeigen, wie man die Dinger zoomen kann - es geht mir jetzt um das Prinzip mit den Interfaces )

Beim Erzeugen der Mainform werden ein Label und ein Edit erzeugt (liegen beide übereinander, ist aber jetzt auch egal).
Mittels des SpinEdits sollen die beiden vergrößert bzw. verkleinert werden.

Die Probleme:
Bei Betätigung des SpinEdits gibt es eine Zugriffsverletzung in der Zoom-Methode.
Die Create-Methode der TBasisklasse (des Helfers) wird nicht aufgerufen - hätte erwartet, dass diese beim Erzeugen der Controls aufgerufen wird. Da habe ich halt das beschriebene Verständnisproblem mit der Kommunikation zwischen Objekt, Interface und Helferklasse.

Hoffe, mir kann jemand weiterhelfen.

Und bitte dran denken - es geht mir jetzt nur um das Prinzip mit diesen Interfaces. Ob diese Art zu zoomen schön ist, oder nicht, ist in diesem Falle vollkommen egal. Das soll nur dem besseren Verständnis meines Anliegens diesen - danke.

[Apollonius]

Wie kommt denn die TBasisklasse in den FHelper? Du kannst nur mit Interfaces arbeiten, die nicht nil sind. Folglich muss der Konstruktor von TEditklasse und TLabelklasse überschrieben werden.
Zur Sache mit dem Cast: Da habe ich auch schon mal dran gehangen. Der Trick ist, dass der internen Cast-Funktion eine GUID übergeben werden muss. Verpasse ITestInterface also eine GUID. Bei Interfaces musst du übrigens zwingend mit dem as-Cast arbeiten, der function-syle-Cast führt fast zwingend zur Zugriffsverletzung, da in der falschen VMT die Funktion gesucht wird (ich will jetzt nicht mit den Interna langweilen, aber wer will, kann ja mal schauen, wie Interface-Methoden eigentlich aufgerufen werden).

[s-off]

Zitat von Apollonius:

Wie kommt denn die TBasisklasse in den FHelper? Du kannst nur mit Interfaces arbeiten, die nicht nil sind. Folglich muss der Konstruktor von TEditklasse und TLabelklasse überschrieben werden.

Ähm - ja - klingt logisch.
Habe nun das Create der Objekte überschrieben und weise darin FHelper eine Instanz der Basisklasse zu - so:

Delphi-Quellcode:

Constructor TLabelklasse.Create(AOwner: TComponent);
Begin
   Inherited;

   FHelper := TBasisklasse.Create(self);
End;

Zitat von Apollonius:

Der Trick ist, dass der internen Cast-Funktion eine GUID übergeben werden muss.

Hui - Sidonius hatte ja in seinem ersten Beispielcode geschrieben, dass eine GUID benötigt würde. Er schrieb aber auch, dass diese automatisch erzeugt wird, was bei mir aber anscheinend nicht der Fall war - ist mir aber ehrlich gesagt auch gar nicht aufgefallen, dass diese fehlte. STRG+UMSCH+G hat geholfen.
Nun kann ich so casten:
(oEdit As ITestInterface).Zoom(SpinEdit1.Value); Nun ja, ich habe wie gesagt, die Create-Methode überschrieben und das casten angepasst.
Ich bekomme nun zumindest schonmal keine Zugriffsverletzung mehr - das gewünschte Zoomen funktioniert aber trotzdem noch nicht - genauer gesagt passiert gar nichts, wenn ich den SpinEdit ändere.
Naja, mal sehen, wo 's hängt.

Danke erstmal, dass ich soweit gekommen bin

Edit: das Zoomen funktioniert nicht, da die Initialwerte im Create der Basisklasse alle als 0 ankommen.
Ich dreh hier nochmal am Reifen....

Edit: Habe mal eine aktualisierte Version hochgeladen

Sorry, aber bei mir hat's schon immer etwas länger gedauert, bis es 'klick' gemacht hat