also ich habe mal wieder ein Problem mit meinem Objekt wirr warr.
Ich habe versucht Objekten ein Parent zu zuweißen, so wie ein TButton und viele andere Objekte das auch haben. Das brauche ich nämlich, weil ich irgendwie auf die übergeordneten Objekte zugreifen möchte.
Ich habs ersteinmal mit nem zeiger ausprobiert. Da traten zwei Probleme auf:

1. der Zeiger muss einen bestimmten Typ haben, dass heißt, dass meine TReifen nur Children von TAuto sein können, aber nicht gleichzeitig auch von TFahrad (was ja aber eigentlich Sinn der sache ist)

2. wenn ich zwei Objekte in ihrer eigenen Unit habe (der Übersicht wegen), dann kann ich zwar meine TReifen als teil von TAuto deklarieren, in dem ich die Reifen unit in die Auto unit einbinde, aber ich kann dann nicht mehr die auto unit in die reifen unit einbinden, um den zeiger zu typisieren (Kreisverweiße).

Ich habs auch schon probiert, alle Objekte in eine Unit zu schreiben, das Ende der Geschichte ist, dass ein Objekt nur die darüber deklarierten Objekte kennt, also auch wieder ein Prob, bei dem nur Auto den Reifen kennt, der Reifen das Auto aber nicht.

bitte helft mir schnell, weil ich muss heute abend gegen 18:00Uhr wieder in die Kaserne zurück und da ist kein Internet, ich will das aber unbedingt vom Tisch haben, um endlich weiter zu kommen.

Danke, an alle, die sich meinem Problem annehmen.

_________________
ist Ihnen schon mal aufgefallen, dass wenn Sie beim Wort Schlagersängerinnen die ersten 6 Buchstaben streichen, das 'e' durch ein 'f' ersetzen, die nächsten 7 Buchstaben rückwärts lesen und dann ebenfalls elemenieren und zusätzlich die beiden nebeneinanderstehenden n's durch ck ersetzen, das Wort 'ficken' ergibt?

Wenn die Klassen in einer Unit stehen, kann man das so machen.

also muss ich Objekte in eine Unit zwängen und alle Objekte zunächst in einen Prototypen Block erwähnen, oder kann ich das auch irgendwie lösen, wenn jedes Objekt eine eigene Unit hat?

_________________
ist Ihnen schon mal aufgefallen, dass wenn Sie beim Wort Schlagersängerinnen die ersten 6 Buchstaben streichen, das 'e' durch ein 'f' ersetzen, die nächsten 7 Buchstaben rückwärts lesen und dann ebenfalls elemenieren und zusätzlich die beiden nebeneinanderstehenden n's durch ck ersetzen, das Wort 'ficken' ergibt?

Du kannst dein Parent auch einfach vom Typ TObject machen und jedesmal ne Typenumwandlung durchführen wenn du irgendwo drauf zugreifst.

Beispiel:



halt die andere Unit dann erst unter implementation einbinden.
Mag auf den ersten Blick umständlich sein, aber die 1 bis 2 Zeilen und die eine Variable die man da mal mehr braucht jucken nicht...
ob man nun gleich FParent vom Typ TReifen hat oder erst ne "lokale" variable pReifen anlegt die man erst zuweisen tut macht echt nicht den unterschied

hmm.. ich glaube ich verstehe da etwas nicht richtig.. es sieht so aus, als würdest du TReifen als Parent von TAuto verwenden in deinem Beispiel...
Im Prinzip soll es ja so funktionieren, dass ich TReifen als Teil von TAuto habe und ich von TReifen immer noch auf die Eigenschaften von TAuto zugreifen kann, um z.B.: die Position des Reifens an die des Autos anzupassen oder so. Das würde mir sehr viel Arbeit abnehmen.

_________________
ist Ihnen schon mal aufgefallen, dass wenn Sie beim Wort Schlagersängerinnen die ersten 6 Buchstaben streichen, das 'e' durch ein 'f' ersetzen, die nächsten 7 Buchstaben rückwärts lesen und dann ebenfalls elemenieren und zusätzlich die beiden nebeneinanderstehenden n's durch ck ersetzen, das Wort 'ficken' ergibt?

Das ist dann aber nicht statisch typsicher.
Es ist in Delphi gar nicht gedacht, dass jede Klasse eine eigene Unit hat. Units haben jeweils einen eigenen Namenraum und sind daher eher z.B. mit Packages in Java vergleichbar. Das sieht man beispielsweise auch an den mitgelieferten VCL Units von Borland.

also sollte ich so viel wie möglich in eine Unit quetschen? Hmm... Dann bricht glaube ich mal wieder die Ära der Endlosen Quellcodes an.

So ich habe neben her noch mal auf Delphie Source nachgeblättert und dort einen Text zum Thema Polymorphie gefunden. Hat das damit zu tun?
Andere Frage, wofür steht das "inherited" im Beispiel von Billi Berserker und was bewirkt seine "dosomething" procedure?

_________________
ist Ihnen schon mal aufgefallen, dass wenn Sie beim Wort Schlagersängerinnen die ersten 6 Buchstaben streichen, das 'e' durch ein 'f' ersetzen, die nächsten 7 Buchstaben rückwärts lesen und dann ebenfalls elemenieren und zusätzlich die beiden nebeneinanderstehenden n's durch ck ersetzen, das Wort 'ficken' ergibt?

Nein, aber was logisch zusammengehört. Und wenn sich Klassen gegenseitig referenzieren, dann scheint das ja der Fall zu sein.

ja huch in dem Beispiel hab ich das ein bissel vertauscht. Aber geht ja nur ums Prinzip das du die Parent variable einfach als TObject deklarierst und die Units erst unter Implementation einbdindest.

Wie man es im Endeffekt macht ist geschmackssache, nur zu viele Klassen in eine Unit läßt es finde ich zu schnell unübersichtlich werden.

Das Inherited ist dazu da um eine Methode aus einer Vorfahrenklasse aufzurufen. Also wie in dem Beispiel von Billi wurde der Konstruktor überschrieben. Da frühere Klassen ja durchaus auch etwas initialisieren möchten muss also der vorherige Konstruktor auch noch aufgerufen werden. Wenn du jetzt nur Create aufrufen würdest würdest du wieder das Create deiner Klasse aufrufen. Du möchtest aber die Vorgängerklasse habe. Und genau das sagst du dem Compiler mit inherited. Das solltest du im übrigen bei allen virtuellen Methoden machen die überschrieben werden.

PS: Schau mal diesen Artikel bei dsdt.info. Kann man sich auch gut ausdrucken und als Lektüre mitnehmen. Rechts oben gibts Download. Das ist schon ein druckfertiges PDF des gesammten Tutorials. Zeit solltest du in der Woche über ja eigentlich ein bisschen haben.

oh, hatte die Frage mit dem inherited komplett überlesen.
Aber wie Lossy schon sagt ist das zum benutzen der überschriebenen funktionen wenn man eine Klasse von einer anderen abgeleitet hat.
Leitet man seine Klassen von TObject ab braucht man das eigentlich nicht, ich hab mir aber angewöhnt es immer zu setzen... kann häßliche Fehler bringen wenn man es an stellen vergißt wo man es braucht. Beim destructor empfiehlt es sich auch wirklich immer ein "inherited Destroy" ans ende zu setzen.

Die procedure .DoSomething war nur als Beispiel gedacht wie du auf das Parent zugreifst und TObject richtig auf ne variable vom typ TReifen umwandelst.



Aber wo wir gerade dabei sind hab ich ne Frage zum constructor an sich.
Irgendwann hatte ich beim erzeugen eines neuen constructors (selbe Parameter wie der alte) mal riesen Probleme damit das er trotzdem immer nur den alten aufgerufen hat. "override" dran klemmen hat irgendwie nicht funktioniert und seitdem klemm ich immer "reinstroduce" an den constructor dran. Damit geht alles prima, aber bin mir irgendwie nicht so sicher ob das so der richtige weg ist. Und was hat es eigentlich mit "virtuel" zu tun? Heißt das lediglich das diese funktion/procedur überschrieben werden kann?

Also das Inherited sollte beim Konstruktor, Destruktor oder virtuellen Methoden grundsätzlich immer aufgerufen werden. Selbst dann wenn man weiß, dass die Vorgängerklasse nichts macht. Irgendwann kommt man vielleicht doch mal auf die Idee und lässt die Klasse etwas machen und dann tut sich nichts und man sucht den Fehler.

Virtuelle Methoden werden intern in der Klasse in eine Tabelle geschrieben. Und wenn man virtuelle Methoden benutzt dann sollte man diese auch grundsätzlich IMMER überschreiben und inherited aufrufen. Sollte jetzt eine Methode eine virtuelle Methode aufrufen, dann wird immer die oberste Methode aufgerufen. Das ist bei nicht virtuellen Methoden nicht immer der Fall. Mal als kleines Beispiel.



Bei dem zweiten Aufruft wird die Methode aus TAuto aufgerufen obwohl wir eine Instanz der Klasse TAudi erstellt haben aber wir benutzen die Instanz aber als Typen TAuto. Ist die Methode hupen aber virtuell und wurde sie überschrieben wird immer die von TAudi zu erst aufgerufen. Bzw mit inherited als erste Anweisung zu erst die Methode aus TAuto und erst dann die von TAudi. Inherited ist nicht an virtuelle Methoden gebunden.

Override geht natürlich nur bei virtuellen Methoden und sorgt dafür, dass als Methode Hupen immer die oberste Methode benutzt wird.

Reintroduce ist eigentlich nicht unbedingt nötig. Solltest du eine virtuelle Methode verdecken, dann sagt der Compiler dir das. Und mit reintroduce sagst du dem Compiler nur, dass du das weißt und bewusst die virtuelle Methode verdecken möchtest. Solltest du allerdings die Klasse wieder wie oben Casten und als TBasisKlasse ansprechen so würde das Verdecken der Methode ignoriert werden.

Konstruktoren sind im übrigen nicht von hause aus virtuell. Die der VCL Komponenten sind sie es, weil Borland es so wollte. Aber der von einem TObject etc. nicht. Warum er bei dir den Alten aufgerufen hat kann ich so nicht sagen. Müsste man wenn dann an Code sehen.