Konstruktoren in Delphi

[Int3g3r]

Zitat:

1. Wen TFehler ein Formular ist, dann gibst du mit inherited Create(...) den Owner an. Also die Komponente/Formular, was dieses Formular wieder freigeben soll.
Hier Self mitzugeben ist Quark.

Ja, TFehler ist eine VLC-Formular. Mir ist einfach nicht klar was ich beim Owner angeben soll.
Dies ist ein eigenständiges Formular, also es hat keinen Owner.

Danke für die Hilfe

[Schokohase]

Wenn es keinen Owner hat, dann ist der Owner wohl nil .

[Int3g3r]

Vielen Dank an alle.

Ich habe jetzt meine Konstruktoren wie im Beispiel erstellt. Lässt sich aber nicht kompillieren.
Wo liegt mein Fehler ?

Delphi-Quellcode:

public
      { Public-Deklarationen }
      Constructor Create; overload;
      Constructor Create(_pnlColor:TColor;_pnlTitle:String;_memoContent:TStringList); overload;
   end;

//.......

constructor TFehler.Create(_pnlColor: TColor; _pnlTitle: String;_memoContent: TStringList);
begin
   Inherited Create(nil);
   setPanelTitle(_pnlTitle);
   setPanelTitleColor(_pnlColor);
   fillMemo(_memoContent);
end;

constructor TFehler.Create;
begin
   Inherited; // Fehler E2008
end;

Meldungen/Fehler beim kompilieren:
[dcc32 Warnung] form_CSVException.pas(24): W1010 Methode 'Create' verbirgt virtuelle Methode vom Basistyp 'TCustomForm'
[dcc32 Warnung] form_CSVException.pas(25): W1010 Methode 'Create' verbirgt virtuelle Methode vom Basistyp 'TCustomForm'
[dcc32 Fehler] form_CSVException.pas(53): E2008 Inkompatible Typen

- Warum erhalte ich den Fehler E2008 ? Wie lässt sich dieser beheben ?
- Wie lassen sich die Warungen beheben ?

[Schokohase]

Probier es mal so

Delphi-Quellcode:

public
      { Public-Deklarationen }
      Constructor Create; reintroduce; overload;
      Constructor Create(_pnlColor:TColor;_pnlTitle:String;_memoContent:TStringList); reintroduce; overload;
   end;

//.......

constructor TFehler.Create;
begin
   Inherited Create(nil);
end;

constructor TFehler.Create(_pnlColor: TColor; _pnlTitle: String;_memoContent: TStringList);
begin
   Create(); // ruft TFehler.Create() auf
   setPanelTitle(_pnlTitle);
   setPanelTitleColor(_pnlColor);
   fillMemo(_memoContent);
end;

[Int3g3r]

Zitat von Schokohase:

Probier es mal so

... So funktioniert es!

Warum funktioniert es nicht wie es im Beispiel steht ?
Was ist mit den Warnugen ?

Danke!

[Schokohase]

Es funktioniert so wie im Beispiel, soweit das Beispiel hier auch zutrifft.
Welche Warnungen? Es dürften keine Warnungen mehr da sein.

[dataspider]

Zitat von Int3g3r:

Zitat:

1. Wen TFehler ein Formular ist, dann gibst du mit inherited Create(...) den Owner an. Also die Komponente/Formular, was dieses Formular wieder freigeben soll.
Hier Self mitzugeben ist Quark.

Ja, TFehler ist eine VLC-Formular. Mir ist einfach nicht klar was ich beim Owner angeben soll.
Dies ist ein eigenständiges Formular, also es hat keinen Owner.

Den Parameter AOwner wegzulassen halte ich für keine gute Idee.
Du musst dich dann zwingend selbst um die Freigabe kümmern.
Nur wenn dein Form (TFehler) immer modal in einen try finally mit Freigabe aufgerufen wird, könnte man es akzeptieren.
Machen würde ich es dennoch nicht. Bei mir haben alle Konstruktoren eines TForms alse ersten Parameter AOwner...
Der Aufruf zum Erzeugen kann dann TFehler.Create(Nil, Color...) oder TFehler.Create(Application, Color...) etc. sein.

Frank

[Dennis07]

Zitat von dataspider:

Den Parameter AOwner wegzulassen halte ich für keine gute Idee.
Du musst dich dann zwingend selbst um die Freigabe kümmern.
Nur wenn dein Form (TFehler) immer modal in einen try finally mit Freigabe aufgerufen wird, könnte man es akzeptieren.
Machen würde ich es dennoch nicht. Bei mir haben alle Konstruktoren eines TForms alse ersten Parameter AOwner...
Der Aufruf zum Erzeugen kann dann TFehler.Create(Nil, Color...) oder TFehler.Create(Application, Color...) etc. sein.

Frank

Oder im Destructor freigeben.
Oder im OnDestroy freigeben.
Das wären alles gültige Alternativen.

[Int3g3r]

Besten Dank für die Antworten.

Leider blicke ich immer noch nicht durch bei den Konstruktoren/Destruktoren.

Z.b

Delphi-Quellcode:

type
  TMail = Class
    smtp: TIdSMTP;
    sslIOHandler: TIdSSLIOHandlerSocketOpenSSL;

    private
    // Private
    public
    // Public
    constructor Create(param1, param2 : String);
    destructor Destroy;
  end;

  var
  Mail : TMail;

implementation

constructor TMail.Create(param1, param2 : String);
begin
  smtp := TIdSMTP.Create(nil);
  sslIOHandler := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
end;

destructor TMail.Destroy;
begin
  if Assigned(smtp) then
      FreeAndNil(smtp);
  if Assigned(sslIOHandler) then
      FreeAndNil(sslIOHandler);
end;

4) Wann ist ein "Inherited" notwenig im Konstruktor/Dekonstruktor ? Sobald von einer Klasse geerbt wird, richtig ?
TMail = Class(TComponent) // Hier währe ein Inherited dann notwendig, richtig ? .

5) Wie bei meinem Beispiel zu sehen habe ich keinen "Standard-Konstruktor" erstellt.
Meine Klasse soll nur mit diesem Konstruktor mit Parameter instanziert werden können.
Bei C# ist ein Standardkonstruktor notwendig, ist das bei Delphi auch der Fall ?

6) Das Beispiel oben lässt sich kompillieren und instanzieren.
Leider verstehe ich aber nicht warum bei Mail.Free der Destruktor nicht abgehandelt wird.
Ich erzeuge Memory-Leaks, was mache ich falsch ?

Lösung zu 6) destructor Destroy; override;
Gruss Int3g3r

PS: Um Memory-Leaks zu Prüfen folgende Zeile beim Projekt->Quelltext einfügen
ReportMemoryLeaksOnShutdown := True;

[Dalai]

Zitat von Int3g3r:

4) Wann ist ein "Inherited" notwenig im Konstruktor/Dekonstruktor ? Sobald von einer Klasse geerbt wird, richtig ?

Setze einfach inmmer ein inherited; in den Konstruktor und Destruktor, bei ersterem (in aller Regel) am Anfang, im Destruktor ans Ende. Jede Klasse erbt von irgendeiner Basisklasse, und wenn es nur TObject ist, die zwar einen leeren Konstruktor hat, aber vielleicht ändert sich das mal.

Zitat:

Meine Klasse soll nur mit diesem Konstruktor mit Parameter instanziert werden können.

Das geht auch irgendwie, im Zweifel mit Prüfung bestimmter Variablen beim Aufruf anderer Methoden der Klasse. Will man den Konstruktor der Basisklasse verdecken und dem Compiler sagen, dass das so in Ordnung ist, kann man ihn mit overload; reintroduce; markieren. IIRC verhindert das aber nicht, den Konstruktor der Basisklasse zu nutzen.

Zitat:

Bei C# ist ein Standardkonstruktor notwendig, ist das bei Delphi auch der Fall ?

Jein. Es gibt immer den Konstruktor der Basisklasse, der immer dann verwendet wird, wenn in der abgeleiteten Klasse keiner definiert ist oder keiner mit passender Parametersignatur gefunden wird. Aber der Konstruktor der Basisklasse lässt nicht immer anwenden, z.B. bei abstrakten Klassen (TStrings).

Zitat:

6) Das Beispiel oben lässt sich kompillieren und instanzieren.
Leider verstehe ich aber nicht warum bei Mail.Free der Destruktor nicht abgehandelt wird.

Jeder Destruktor sollte/muss mit override; markiert werden, damit der der abgeleiteten Klasse gerufen wird, nicht der der Basisklasse. Tut man das nicht, gibt der Compiler eine Warnung, soweit ich weiß.

Grüße
Dalai