Forward in Klassen funktioniert nicht

[ATS3788]

Hallo ich mache da wohl einen Denkfehler und komme nicht drauf

Delphi-Quellcode:

type
  // Define the classes in this Unit at the very start for clarity
  TForm1 = Class;          // This is a forward class definition


  TFruit = Class(TObject)  // This is an actual class definition :
    // Internal class field definitions - only accessible in this unit
     private
       t        : TForm1;  // Warum ist die variable ungültig !
       isRound  : Boolean;
       length   : single;
       width    : single;
       diameter : single;
    // Fields and methods only accessible by this class and descendants
    procedure SetForm(const Value : TForm1);
     protected
    // Externally accessible fields and methods
     public

      // 2 constructors - one for round fruit, the other long fruit
       constructor Create(diameter : single);               overload;
       constructor Create(length : single; width : single); overload;
    // Externally accessible and inspectable fields and methods
     published
      // Note that properties must use different names to local defs
       property round : Boolean
         read   isRound;
       property len   : single
         read   length;
       property wide  : single
         read   width;
       property diam  : single
         read   diameter;
  end;                    // End of the TFruit class definition

  // The actual TForm1 class is now defined
   TForm1 = Class(TForm)
    Button1: TButton;
    Button2: TButton;
     procedure FormCreate(Sender: TObject);
     procedure ShowFruit(fruit : TFruit);
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
   private
    // No local data
    f : TFruit;
   public
    // Uses just the TForm ancestor class public definitions
   end;

 var
   Form1: TForm1;

 implementation

 {$R *.dfm}

// Create a round fruit object
 constructor TFruit.Create(diameter: single);
 begin
  // Indicate that we have a round fruit, and set its size
   isRound       := true;
   self.diameter := diameter;
 end;

// Create a long fruit object
 constructor TFruit.Create(length, width: single);
 begin
  // Indicate that we have a long fruit, and set its size
   isRound     := false;
   self.length := length;
   self.width  := width;
 end;


 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;


// Form object - action taken when the form is created
 procedure TForm1.Button1Click(Sender: TObject);
begin
FormCreate(Sender);
end;

procedure TForm1.Button2Click(Sender: TObject);
 var
 Fruit : TFruit;
begin
 Fruit := TFruit.Create(23);

  ShowFruit(Fruit);
end;

procedure TForm1.FormCreate(Sender: TObject);
 var
   apple, banana : TFruit;
 begin
 f.SetForm(self);

  // Let us create our fruit objects
   apple  := TFruit.Create(3.5);
   banana := TFruit.Create(7.0, 1.75);

  // Show details about our fruits
   ShowFruit(apple);
   ShowFruit(banana);
 end;

// Show what the characteristics of our fruit are
 procedure TForm1.ShowFruit(fruit: TFruit);
 begin
   if fruit.round
   then ShowMessage('We have a round fruit, with diam = '+
                    FloatToStr(fruit.diam))
   else
   begin
     ShowMessage('We have a long fruit');
     ShowMessage('    it has length = '+FloatToStr(fruit.len));
     ShowMessage('    it has width  = '+FloatToStr(fruit.wide));
   end;
 end;

 end.

http://www.delphibasics.co.uk/RTL.asp?Name=Class
Ich habe das Beispiel ein wenig abgeändert
Meine Frage wie kann ich dem Object TFruit
mitteilen das TForm1 Object mitteilen.

[Dejan Vu]

Welche Meldung kommt?
Das Feld 't' wird nicht verwendet (dem Wert wird nur etwas zugewiesen), vielleicht meckert dein Delphi darüber...

[bcvs]

Dein Ansatz ist schon richtig, Du musst nur das Object f erst erzeugen, bevor du darauf zugreifst:

Delphi-Quellcode:

f:=TFruit.Create(0);
f.SetForm(self);

Und du musst dafür sorgen, dass f irgendwo wieder freigegeben wird, am Besten im OnDestroy.

[bernau]

Warum muss TFruit eigendlich etwas von TForm1 wissen? Du greifst in TFruit in keiner Procedure auf TForm1 zu.

OK. Quellcode ggf. nicht komplett. Ich rate mal. Wenn du auf der Form irgend etwas von TFruit anzeigen möchtest, dann konnte die Form das selber übernehmen. Du brauchst nur ein TNotify-Event anlegen. Damit kann TFruit dem TForm1 mitteilen, daß was geändert wurde und Form1 zeichnet selber.

P.S.: Ich will nicht etwas gegen Forwarding sagen. Verwende ich selber sehr oft. Kommt aber auf die Situation an.

[DeddyH]

Das sehe ich ähnlich. Für mich hat Klassenforwarding ein Geschmäckle, denn es wird meist dazu benutzt, Klassen untereinander bekannt zu machen. Das ist zwar nicht in jedem Fall immer einfach zu umgehen, elegant ist das IMO allerdings nicht.

[BadenPower]

Zitat:

Zitat von DeddyH (Beitrag 1283849)

Für mich hat Klassenforwarding ein Geschmäckle, denn es wird meist dazu benutzt, Klassen untereinander bekannt zu machen.

Dann darfst Du aber nicht programmieren, denn die halbe VCL kann nur durch voherige Bekanntmachung weiterer Klassen funktionieren.:lol:


Class-Forwarding heisst ja nur, "Hallo mich gibt es".

[DeddyH]

Nur weil im letzten Jahrtausend etwas in der VCL gemacht wurde, heißt das ja noch nicht, dass das auch gut ist.

[BadenPower]

Zitat:

Zitat von DeddyH (Beitrag 1283866)

Nur weil im letzten Jahrtausend etwas in der VCL gemacht wurde, heißt das ja noch nicht, dass das auch gut ist.

Eine gute Lösung ist aber immer dann eine gute Lösung, wenn es keine andere Lösung gibt.

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

[DeddyH]

Zitat:

Zitat von BadenPower (Beitrag 1283874)

Abhängigkeiten untereinander

Genau das ist doch der Knackpunkt. Hier würde ich mich bereits fragen, ob das wirklich sein muss oder nicht doch auch anders geht.

[BadenPower]

Zitat:

Zitat von DeddyH (Beitrag 1283879)

Zitat:

Zitat von BadenPower (Beitrag 1283874)

Abhängigkeiten untereinander

Genau das ist doch der Knackpunkt. Hier würde ich mich bereits fragen, ob das wirklich sein muss oder nicht doch auch anders geht.

Ja das muss sein.

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".

"Mensch" muss entwerder "Sperma" oder "Eizelle" kennen. "Eizelle" muss "Sperma" kennen und umgekehrt, sonst wissen die gar nicht, dass sie zusammenfinden müssen. Haben sie sich gefunden, dann müssen sie aber wiederum die Klasse "Mensch" kennen, den sie zusammen daraus entwickeln wollen.

Ich will jetzt erst gar nicht auf die Proceduren der Unterklassen "Männlich" und "Weiblich" eingehen, welche es "Sperma" und "Eizelle" ermöglichen sich zu treffen.

[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.

[stahli]

Das ist ja auch nicht generell ein Problem und oft sinnvoll.

Man kann dann aber die beteiligten Klassen nicht mehr (so leicht) verselbständigen und an anderer Stelle einsetzen.

Auch wenn sich ein Projekt immer weiter vergrößert kann das irgendwann unübersichtlich werden.
Dann würdest Du vielleicht gern eine Klasse in eine eigene Unit legen, da aber alle Klassen mit allen anderen umgehen geht das dann nicht mehr.

Forward Deklaration ist sicher kein Problem, aber bei komplexen Projekten ist es besser, von Anfang an auf ordentliche Trennung zu achten.

[bernau]

Zitat:

Zitat von BadenPower (Beitrag 1283982)

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.

Ich hatte ja eingangs geschrieben, daß auch ich gelegendlich eine Forward-Deklaration verwende. Manchmal geht es nicht anders. Aber wenn es möglich ist, dann vermeiden.

Das ist wie mit Units, die sich gegenseitig kennen müssen (Stichwort Zirkuläre Referenz). Wenn du so etwas drin hast.... Nee. Versuch es du vermeiden.

[BadenPower]

[QUOTE=bernau;1283985]

Zitat:

Zitat von BadenPower (Beitrag 1283982)

Stichwort Zirkuläre Referenz

Und genau deshalb gibt es ja die Möglichkeit einer Vorwärts-Deklaration von Klassen.

Und weil sie zusammengehören und direkt von einander abhängig sind, stehen sie auch in der selben Unit.

Und eine solche Ehe soll der Programmierer dann auch nicht scheiden.

[Sir Rufo]

Immer wenn ich auf mein Knie drücke tut es weh, genauso am Arm und am Ohr, sowie am Fuß, eigentlich überall.

Jetzt habe ich meine Diagnose: Finger gebrochen.

Delphi-Quellcode:

// Form object - action taken when
procedure TForm1.FormCreate(Sender: TObject);
 var
   apple, banana : TFruit;
 begin
  // ACHTUNG, DIESE ZEILEN EINFÜGEN
  if not Assigned( f ) then
    raise Exception.Create( 'Finger gebrochen!' );
  // DAS WAR ES SCHON - AUSPROBIEREN - WAS SEHEN WIR?
   f.SetForm(self);

  // Let us create our fruit objects
   apple := TFruit.Create(3.5);
   banana := TFruit.Create(7.0, 1.75);

  // Show details about our fruits
   ShowFruit(apple);
   ShowFruit(banana);
 end;

[Dejan Vu]

Zitat:

Zitat von BadenPower (Beitrag 1283982)

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.

Wegen der Wiederverwendbarkeit, z.B. Zirkuläre Referenzen sind eigentlich nie sinnvoll. Es verbindet beide Klassen unauslöschlich miteinander. Meistens (eigentlich immer) ist es ein Designfehler. Mir fällt kein sinnvolles Beispiel ein, wo zwei *Klassen* sich kennen müssen. A verwendet B, aber B muss A konkret nicht kennen, höchstens ein von A implementiertes Interface. Und -wupps- haben wir die zirkuläre Referenz aufgelöst.

Es gibt mittlerweile (also seit ca. 20 Jahren) Grundregeln moderner Softwarearchitektur, die man befolgen kann oder auch nicht. Nur wenn man sie nicht befolgt, dann muss man sich nicht wundern, wenn man dann in einer Diskussion, die sich am Rande auch um diese Regeln dreht, Gegenargumente bekommt. Oder teilweise Kopfschütteln.

Zitat:

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

Wie fein. Andere Leute finden Bollerwagen toll. Aber das Transportgewerbe setzt gemeinhin auf bessere Lösungen.

[DeddyH]

:thumb:

[BadenPower]

Zitat:

Zitat von Dejan Vu (Beitrag 1284008)

Es gibt mittlerweile (also seit ca. 20 Jahren) Grundregeln moderner Softwarearchitektur, die man befolgen kann oder auch nicht. Nur wenn man sie nicht befolgt, dann muss man sich nicht wundern, wenn man dann in einer Diskussion, die sich am Rande auch um diese Regeln dreht, Gegenargumente bekommt.

Mich wundert es nicht, wenn ich für meine Meinung Gegenargumente bekomme, aber was mich wundert ist, dass man dann mit Delphi arbeitet, wenn man sich ausschließlich an "Grundregeln moderner Softwarearchitektur" halten will.

Eine Funktion ist immer dazu da, benutzt zu werden.

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen, oder seine komplett selbst programmierte VCL zu benutzen.
Sollte man allerdings tun, wenn man auf die "Grundregeln moderner Softwarearchitektur" besteht.

[Dejan Vu]

Zitat:

Zitat von BadenPower (Beitrag 1284011)

Eine Funktion ist immer dazu da, benutzt zu werden.

Hmmm. Ein 'goto' auch? ;-)

Zitat:

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen,

Doch. Programmierer, die was auf sich halten (oder sich das einbilden), schon. Ein TTabSheet möchte vielleicht einmal in einem anderen Container sein, als in einem TPageControl. Das geht so aber nicht. Wäre das TTabsheet nur abhängig von einem Container, der die notwendigen Methoden des TPageControl implementiert, ginge das.

Zitat:

aber was mich wundert ist, dass man dann mit Delphi arbeitet, wenn man sich ausschließlich an "Grundregeln moderner Softwarearchitektur" halten will.

Och, auch mit Delphi kann man recht sauberen Code produzieren. Man muss einfach nur die Anti-Pattern vermeiden.

Im Übrigen gilt in der modernen Softwarearchitektur auch und besonders, das man bestehende Frameworks benutzen sollte, wenn dies (TOC) günstiger ist, als selbst etwas zu entwickeln. Also verwende ich zähneknirschend die VCL und auch mal so ein in seiner Freiheit eingeschränktes TTabSheet.

[BadenPower]

Zitat:

Zitat von Dejan Vu (Beitrag 1284013)

Och, auch mit Delphi kann man recht sauberen Code produzieren.

Du widersprichst Dir selbst.

Einerseits sagst Du, dass Forward-Deklarationen von Klassen nicht den "Grundregeln moderner Softwarearchitektur" entsprechen, andererseits verwendest Du Delphi, welches voll ist mit Klassen-Forward-Deklarationen.

Entweder sind dann auch Klassen-Forward-Deklarationen "sauberer Code" oder Dein Programm hat KEINEN sauberen Code, denn Dein Programm besteht zu einem sehr großen Teil aus Delhi-Code.

Du solltest Dich für eine Variante entscheiden.

Zitat:

Zitat von Dejan Vu (Beitrag 1284013)

Zitat:

Kein Mensch würde darauf kommen TPageControl und TTabSheet zu trennen,

Doch. Programmierer, die was auf sich halten (oder sich das einbilden), schon.

Also ich habe ein eigenes TPageControl und ein eigenes TTabSheet und habe es dennoch nicht übers Herz gebracht eine unnötige 3. Klasse zu erstellen, damit sich beide Klassen unterhalten können oder gar in zwei verschiedenen Units ihr Dasein zu fristen.

Zitat:

Zitat von Dejan Vu (Beitrag 1284013)

Zitat:

Zitat von BadenPower (Beitrag 1284011)

Eine Funktion ist immer dazu da, benutzt zu werden.

Hmmm. Ein 'goto' auch? ;-)

Selbstverständlich.

Auch ein "Goto" war ein sehr gut einzusetzender und effektiver Befehl.

[ATS3788]

Sir Rufo:thumb:

Ohhhh Danke Dir, das Object wurde noch nicht erstellt Oooohhhhhhhhhh
Nur warum ging das mit der Lokalen Variablen
dann wäre mir das auch aufgefallen.
Ein schönes Weihnachtsfest.

Zitat:

http://www.delphipraxis.net/183177-d...scheidung.html
Schaut doch mal in den Beitrag von mir. Knapp 700€ für XE7 sind viel Geld
wenn man kein Geld mit Programmieren verdient. Vielleicht habt ihr ja noch
eine gute Idee.

[BadenPower]

Zitat:

Zitat von ATS3788 (Beitrag 1284029)

Sir Rufo:thumb:
Ohhhh Danke Dir, das Object wurde noch nicht erstellt Oooohhhhhhhhhh

Die Antwort hat Dir bcvs bereits auf der 1. Seite im 3. Post gegeben und im Post 16 auf Seite 2 nochmals darauf hingewiesen.

[himitsu]

Der Stack existiert immer, egal ob es das Objekt gibt oder nicht,
drum funktionieren lokale Variablen immer.

Globale Variablen liegen auf dem Heap und der ist auch immer da.

Felder (Veriablen in der Klasse) liegen immer in der Klassen-Instanz und ist die weg, dann sind die auch weg. :stupid:

Die Variable (mit der Klasseninstanz) wird als Self in die Methode reingegeben und solange man nicht auf Self (also auf irgendwas in der Instanz) zugreift, kann auch nichts passieren.
Die Methode wird dann quasi zur Klassen-Methode (class function).

[bcvs]

Zitat:

Zitat von BadenPower (Beitrag 1284036)

Zitat:

Zitat von ATS3788 (Beitrag 1284029)

Sir Rufo:thumb:
Ohhhh Danke Dir, das Object wurde noch nicht erstellt Oooohhhhhhhhhh

Die Antwort hat Dir bcvs bereits auf der 1. Seite im 3. Post gegeben und im Post 16 auf Seite 2 nochmals darauf hingewiesen.

Und ich habe schon gedacht, meine Posts würden irgendwie verschluckt und außer mir sieht sie niemand.:cry:

[Dejan Vu]

Ich für meinen Teil hab die Schale Popcorn schon hier zu stehen gehabt und gewartet und geschmunzelt.

[BadenPower]

Zitat:

Zitat von bcvs (Beitrag 1284047)

Und ich habe schon gedacht, meine Posts würden irgendwie verschluckt und außer mir sieht sie niemand.:cry:

Delphi-Quellcode:

procedure ExtendDiscussion(AAnswer: TAnswer; AQuestioner: TQuestioner; AReader: TPostReader)
begin
  if ((AAnswer.Correct) and (AReader = AQuestioner)) then
   begin
    AAnswer.Visible := false;
   end;
end

[himitsu]

Zitat:

Zitat von bcvs (Beitrag 1284047)

Zitat:

Zitat von BadenPower (Beitrag 1284036)

Die Antwort hat Dir bcvs bereits auf der 1. Seite im 3. Post gegeben und im Post 16 auf Seite 2 nochmals darauf hingewiesen.

Und ich habe schon gedacht, meine Posts würden irgendwie verschluckt und außer mir sieht sie niemand.:cry:

Und nochmal "unüberlesbar" in der #19, aber wen interessiert sowas ... liest ja eh keiner :stupid:

Vielleicht gibt es ja ein Plugin, welches richtige Antworten schweinchenrosa einfärbt?

[Sir Rufo]

Ich wollte hier niemandem die Antwort stehlen, aber im Hinblick auf

http://www.delphipraxis.net/1283851-post4.html

empfand ich es hier als angebracht mit dem gesamten Westerwald zu winken als nur mit dem Zaunpfahl. Ein weiteres Darauf-Herumreiten, warum diese oder jene schon frührere gegebene Antwort nicht gesehen wurde sollte sich in Anbetracht der besonderen Situation erübrigen.

[BadenPower]

:thumb::thumb::thumb:

[Dejan Vu]

Zitat:

Zitat von BadenPower (Beitrag 1284062)

Delphi-Quellcode:

procedure ExtendDiscussion(AAnswer: TAnswer; AQuestioner: TQuestioner; AReader: TPostReader)
...

Zitat:

Zitat von BadenPower (Beitrag 1284085)

:thumb::thumb::thumb:

Wie ein Fähnchen im Wind. ;-)

Asche auf unser Haupt.

[BadenPower]

Zitat:

Zitat von Dejan Vu (Beitrag 1284154)

Wie ein Fähnchen im Wind. ;-)

Ich fand die Einstellung von Sir Rufo einfach super uns auf dezente Weise auf etwas aufmerksam zu machen, was ich zum Beipiel nicht gelesen hatte, da mich das Thema dort nicht interessiert hatte.

Soetwas ist es immer Wert und hat absolut nichts mit einem Fähnchen im Wind zu tun.

Dafür nochmals 3x Daumen hoch für Sir Rufo.:thumb::thumb::thumb: