Hallo und danke erst einmal fuer die raschen Antworten.
Also zuersteinmal zum Verdecken und Ueberladen
Ich verstehe es nicht. Auch anhand des Beispiels nicht. Besser waere eine exakte Definition von Verbergen und Ueberschreiben im Zusammenhang mit Virtual (und ohne dieses).
Wir haben in C++ gelernt, dass es im Zuge der Vererbung zwei Moeglichkeiten gibt, sich auf eine bereits definierte Methode zu beziehen:
- Ueberladen - Definition einer Methode mit bereits vorhandenem Namen aber anderer Signatur
- Ueberschreiben - Definition einer bereits vorhandenen Methode (die ueberschriebene steht dann noch immer zur Verfuegung) - Dabei ist virtual NICHT ZWINGEND
Virtual wird erst erforderlich, wenn dynamisches Binden gewuenscht ist, also erst zur Laufzeit entschieden wird, welche der vielen "gleichen" Methoden ausgefuehrt werden soll (aber auch nur bei Zeigern und Referenzen). Ohne
virtual wird ansonsten immer die Methode des Datentyps ausgefuehrt, welche die das Objekt beinhaltende Variable hat, unabhaengig davon, welchen Datentyp das Objekt in Wirklichkeit hat ...
Hier scheint das naders zu sein: Hier muss zum Ueberladen wohl immer die Basismethode virtual sein ...
--> Dringender Erklaerungsbedarf zu dem ganzen Komplex (in Form einer sauberen, klar abgegrenzten Definition)
Zum Published
Ok, das mit dem Objektinspektor wusste ich.
Heisst das aber, dass auch alle Methoden, die durch die Form-Komponenten benutzt werden (Ereignisbehandlungsroutinen, z. B. ButtonClick, EditKeydown ...) auch published sein muessen?? Bzw. Methoden, welche von dieses Ereignisbehandlungsroutinen benutzt werden??? Das waere ja ein Schlag in die Magengrube der Objektorientierung ...
So waeren ja nur noch Felder und Methoden geschuetzt, welche nichts mit der Form zu tun haetten.
Ist das richtig?
(Ausgangspunkt ist natuerlich, dass ich mit dem Objektinspektor arbeiten will)
Zum Virtuellen Konstruktor
Also dass mein eigens entwickelter Konstruktor nicht aufgerufen wird, halte ich fuer unwahrscheinlich.
Ich rufe ihn ja selbst explizit auf. In einer anderen Form. Also meine erste Form erzeugt die zweite mit dem selbstentwickelten Konstruktor. Dabei entsteht die Warnung. Auch bei
overload (da ich ihn ja ueberlade).
Aehnlich verfahre ich auch mit der ersten Form: Dafuer erstelle ich im Hauptprogramm eine lokale Variable, welche ich mit einem neuen Form-Objekt durch den Standardkonstruktor
Create(AOwner: TComponent) initialisiere; danach kommt erst CreateForm(...).
Bitte dafuer noch einmal meine Ueberarbeitung des Hauptprogramms im ersten Beitrag ansehen.
Habe wie gesagt ALLE globalen Variablen (*Gaensehaut bekomm*) entfernt und eine lokale Variable fuer das Hauptprogramm angelegt.
Aber zu der Aussage, die du triffst, >shmia<:
Dann koennte ich ja alle Felder, die ich einer Form hinzufuege nur von aussen "nach-initialisieren", mit Set-Methoden, denn Konstruktoren darf ich laut deiner Aussage dafuer nicht schreiben.
Auch das waere ein Verstoss gegen das Prinzip der
OOP. Jedes Objekt soll sich selbst verwalten und die Konsistenz der eigenen Daten sicherstellen.
Entschuldigt, wenn ich rechthaberisch klinge, aber genau deswegen eroeffnete ich das Thema, weil es momentan heftige Kollisionen mit meinem bisherigen Verstaendnis der
OOP (aus anderen Sprachen) gibt.
Bis dann,
Ri
"Es amüsiert mich immer wieder, wenn Menschen all ihr Unglück dem Schicksal, dem Zufall oder dem Verhängnis zuschreiben, während sie ihre Erfolge oder ihr Glück mit ihrer eigenen Klugheit, ihrem Scharfsinn oder ihrer Einsicht begründen."