Forward in Klassen funktioniert nicht

[Sherlock]

Und alles liegt unter der Klasse Lebewesen.

Sherlock

[BadenPower]

Zitat:

Zitat von Sherlock (Beitrag 1283894)

Und alles liegt unter der Klasse Lebewesen.

Und diese Klasse wurde von den Delphi-Entwicklern bereitgestellt.

Das kann nur so sein, da sie aussergewöhnlich viele Fehler enthält.

[himitsu]

Zitat:

Zitat von ATS3788 (Beitrag 1283828)

Delphi-Quellcode:

t        : TForm1;  // Warum ist die variable ungültig !

Zitat:

Zitat von Dejan Vu (Beitrag 1283830)

Welche Meldung kommt?

Wenn es meistens egal ist, was das für eine Form ist, dann kann man für Variable und Setter natürlich auch einfach TForm verweden.

Man könnte natürlich auch die Form als Owner übergeben und dann über den Owner auf die Form casten.


Ansonsten enthalte ich mich erstmal allen Spekulationen und warte auf die Antwort zur Frage.
Was heißt "ungültig"?
Und gibt es noch weitere Fehlermeldungen? (vonwegen Folgefehler usw.)

[Dejan Vu]

Zitat:

Zitat von BadenPower (Beitrag 1283892)

Ja das muss sein.

Nein. Muss es nicht.

Zitat:

Selbst das Leben besteht nur, weil es solche Abhänigkeiten kennt.
Da gibt es die Klassen "Sperma", "Eizelle" und "Mensch". Die Klasse "Mensch" sogar in den Unterklassen "Männlich" und "Weiblich".

Du verwechselst 'Abhängigkeiten' mit 'Weiterentwicklung'.

In der Softwareentwicklung müssen die Klassen nichts voneinander wissen. Eine Eizelle und ein Mensch können sehr gut existieren, ohne einander zu kennen.

Zitat:

Zitat von BadenPower (Beitrag 1283874)

Oder wie würdest Du sonst Abhängigkeiten untereinander bekanntmachen?
Jetzt nicht speziell für Delphi, sondern auch gerne ganz allgemein.

Abhängigkeiten sollten auf ein Minimum beschränkt sein. Eine Klasse soll nur die Dinge wissen, die gerade notwendig sind, damit sie (die Klasse) ihre Aufgabe erledigt kann. Mehr nicht.

Wechselseitige Abhängigkeiten sind dagegen erstens zu vermeiden und zweitens immer vermeidbar. Es reicht ja schon, ein Interface einzuführen. Alternativ dazu kann ich auch mit Events arbeiten.

Wechselseitige Abhängigkeiten führen zudem dazu, das die Klasse ihre Allgemeingültigkeit und Wiederverwendbarkeit einschränkt, wenn nicht sogar verliert.

[ATS3788]

Huch so viele schon

Delphi-Quellcode:

procedure TFruit.SetForm(const Value : TForm1);
  var
  f1 : TForm1;
  begin
    t := nil; // Nicht mal das geht
    f1 := Value; // Das würde gehen
    t := Value; // und das ist der Grund für den Eintrag
  end;

Also wenn // t := nil;
dann kann ich das Object mit Value an f1 übergeben
nur t in private deklariert das geht gar nicht dann gibt es eine EAccessViolation Schutzverletzung.
Ob das elegant ist, ist erst mal egal.
Es geht ja auch darum mal was anderes zu probieren und zu lernen.
Ich habe die Komponente comport411f
eine tolle Freeware Komponente wo das funktioniert und ich verstehe nicht warum
das hier nicht funktioniert.

[bcvs]

Hast du meinen Hinweis von #3 mal ausprobiert?

[BadenPower]

Zitat:

Zitat von Dejan Vu (Beitrag 1283912)

In der Softwareentwicklung müssen die Klassen nichts voneinander wissen.

Und wie nutzt man eine Klasse, welche niemand kennt?

Was glaubst Du für was die Uses-Klausel da ist. Um Klassen vor einander zu verstecken, oder dafür, dass die Klasse von anderen Klassen erfährt?

Zitat:

Zitat von Dejan Vu (Beitrag 1283912)

Eine Eizelle und ein Mensch können sehr gut existieren, ohne einander zu kennen.

Das ist richtig.

Denn irgendein Mensch muss irgendeine Eizelle nicht kennen.

Aber die Klassen müssen sich gegenseitig kennen, sonst würde die Menschheit aussterben.

Zitat:

Zitat von Dejan Vu (Beitrag 1283912)

Wechselseitige Abhängigkeiten führen zudem dazu, das die Klasse ihre Allgemeingültigkeit und Wiederverwendbarkeit einschränkt, wenn nicht sogar verliert.

:?::?::?:

[bernau]

Zitat:

Zitat von BadenPower (Beitrag 1283966)

Zitat:

Zitat von Dejan Vu (Beitrag 1283912)

In der Softwareentwicklung müssen die Klassen nichts voneinander wissen.

Und wie nutzt man eine Klasse, welche niemand kennt?

Was glaubst Du für was die Uses-Klausel da ist. Um Klassen vor einander zu verstecken, oder dafür, dass die Klasse von anderen Klassen erfährt?

Es geht nicht darum, daß keiner keinen kennt. Das voneinander Wissen sollte nur in eine Richtung gehen.

Klasse A kennt Klasse B aber nicht umgekehrt.

Zum Thema Uses: Wenn ich eine Procedure aus den Sysutils verwenden möchte, dann sollte diese die Procedure aus SysUtils kennen, aber die Procedure aus Sysutils muss nicht unbedingt etwas von meiner procedure wissen.

[himitsu]

Zitat:

Zitat von ATS3788 (Beitrag 1283915)

Huch so viele schon

Delphi-Quellcode:

procedure TFruit.SetForm(const Value : TForm1);
  var
  f1 : TForm1;
  begin
    t := nil; // Nicht mal das geht
    f1 := Value; // Das würde gehen
    t := Value; // und das ist der Grund für den Eintrag
  end;

Also wenn // t := nil;
dann kann ich das Object mit Value an f1 übergeben
nur t in private deklariert das geht gar nicht dann gibt es eine EAccessViolation Schutzverletzung.
Ob das elegant ist, ist erst mal egal.
Es geht ja auch darum mal was anderes zu probieren und zu lernen.
Ich habe die Komponente comport411f
eine tolle Freeware Komponente wo das funktioniert und ich verstehe nicht warum
das hier nicht funktioniert.

Wetten hier hat jemand vergessen seine TFruit-Instanz zu erzeugen, zuzuweisen oder Dergleichen? :roll:

Immer schön, wenn das Wichtigste fehlt und man erst mühsam danach fragen muß.
Und am Ende hatte es rein garnichts mit der ursprünglichen Frage zu tun.

[BadenPower]

Zitat:

Zitat von bernau (Beitrag 1283971)

Das voneinander Wissen sollte nur in eine Richtung gehen.

Aber um dann miteinander arbeiten zu können, müssen beide einen 3. kennen.

Warum also einen dritten hinzuziehen, wenn die beiden Klassen zusammengehörig sind und gegenseitig miteinander über den direkten Weg agieren können.

Bei den Proceduren und Funktionen, welche in einer Klasse angelegt sind macht sich doch auch niemand Gedanken darüber, dass sich ALLE gegenseitig kennen und vorwärts deklariert sind.


Also:
Ich bin für Vorwärts-Deklarationen auch bei Klassen.