Zugriff auf Objekt in Klasse

[FediDelPr]

Im Umgang mit Klassen (eigene Definitionen) bin ich noch nicht wirklich geübt.

Jetzt bin ich aber doch einigermassen erstaunt darüber, dass der Compiler folgendes
frisst:

Ich definiere eine eigene Klasse:

Code:

  TEmailCoreObject = CLASS(TObject)
    IMAPClient: TIdIMAP4;
    ...

und greife dann darauf zu, ohne vorher eine Instanz gebildet zu haben.

Code:

    IMAPClient.Host := 'imaps.gmail.com';
    IMAPClient.Port := 993;

Warum geht das ?
Macht das Sinn ?

Mit einer Typendeklaration RECORD ... geht das nicht, ich muss zuerst eine
Variable mit diesem Typ definieren.

Habe ich etwas nicht kapiert ?

[FediDelPr]

Der Fall liegt vermutlich etwas komplizierter. Studiert im Moment noch
nicht zuviel daran herum.
Ich werde ein Präzisierung nachliefern.

[haentschman]

Moin...

Zitat:

dass der Compiler folgendes frisst ... Warum geht das ?

...und zur Laufzeit macht es Bummm!

Delphi-Quellcode:

TEmailCoreObject = CLASS(TObject)
  IMAPClient: TIdIMAP4;

...Felder einer Klasse werden immer mit F gekennzeichnet. Da liegt u.a. an einer Property...wenn man es braucht.
StyleGuide:
https://www.delphi-treff.de/object-pascal/styleguide/
Bitte denke auch ggf. an die Sichtbarkeiten...wenn benötigt.
http://docwiki.embarcadero.com/RADSt...assenelementen

Besser:

Delphi-Quellcode:

TEmailCoreObject = class
private
  
protected
  FIMAPClient: TIdIMAP4; // protected...weil das auch in der abgeleiteten Klasse nach Core verfügbar sein soll, oder?
public
  constuctor Create;
  destructor Destroy; override;
  property IMAPClient: TIdIMAP4 read FIMAPClient write FIMAPClient; // ggf. als property nach "Außen"
end;

...

constructor TEmailCoreObject.Create;
begin
  FIMAPClient := TIdIMAP4.Create;
end;

destructor TEmailCoreObject.Destroy;
begin
  FIMAPClient.Free;
  inherited;
end;

[FediDelPr]

@Haentschman
danke, werde das genauer ansehen.

Ich hab's jetzt nochmals genauer angeschaut:

Eine Instanz von IMAPClient oder neu jetzt FIMAPClient wurde erzeugt und
das überrascht mich jetzt, ohne vorher eine Instanz von TEmailCoreObject
gebildet zu haben. Es existiert also nur:

Code:

TEmailCoreObject = CLASS(TObject)
   ...
 PUBLIC
   FIMAPClient: TIdIMAP4;
END;

und eine uninitialisierte Instanz von TEmailCoreObject in einem übergeordneten Modul
(ohne je ein Create durchgeführt zu haben). Und es läuft trotzdem.

Nebenbei:
Sehe ich das richtig, dass FIMAPClient ohne Schlüsselwort mit PUBLIC gleichzusetzen
ist? Mindestens so scheint es bei mir zu funktionieren.

[himitsu]

Der Name ist vollkommen egal.

Und egal ob Record oder Class, die Instanz von TIdIMAP4 mußt du immer erstllen.
Es wird da garnichts automatisch gemacht.

Beim Class muß natürlich auch noch die Instanz von TEmailCoreObject erstellt werden.


Einziger Unterschied, das Feld (FIMAPClient) wird in der Klasse automatisch mit NIL initialisiert.
Ob das auch bei dem Record passiert, hängt davon ab, wo diese Variable liegt. (lokale Variablen in Prozeruden/Methoden sind nie initialisiert)

[haentschman]

Moin...

Zitat:

das überrascht mich jetzt, ohne vorher eine Instanz von TEmailCoreObject

Du darfst aber die Komponente nicht auf die Form ziehen...Weil das riecht danach.

Zitat:

Sehe ich das richtig, dass FIMAPClient ohne Schlüsselwort mit PUBLIC gleichzusetzen

Prinzipiell ja. Aber...ich würde das den Compiler nicht selbst entscheiden lassen...ich entscheide wer was ist! Später heraus willst du vieleicht Felder hinzufügen, die nicht Properties sind...dann greift die Sichtbarkeit (public, private, protected). Also, warum nicht gleich so?

[himitsu]

Zitat:

Sehe ich das richtig, dass FIMAPClient ohne Schlüsselwort mit PUBLIC gleichzusetzen

Ja
und auch NEIN.

Normalerweise ist bei Objekten und auch Records der Default das "public".

ABER alles ab TComponent TPersistent, da ist es "published", da {$M+} !
http://docwiki.embarcadero.com/RADSt...tionen_(Delphi)
Darum sind die Komponenten-Variablen in TForms am Anfang eben auch published, damit der DFM-Reader diese Varialen und die EventMethoden finden kann.

[TurboMagic]

Zitat von FediDelPr:

Nebenbei:
Sehe ich das richtig, dass FIMAPClient ohne Schlüsselwort mit PUBLIC gleichzusetzen
ist? Mindestens so scheint es bei mir zu funktionieren.

Ja. Das sollte man selber aber besser vermeiden, da es nicht im Sinne der OOP ist.
Nur VCL/FMX Klassen brauchen dieses Verhalten, da alle in dieser "nicht" Sektion
deklarierte Felder die auf der Form liegenden Komponenten sind, deren eigentliche
Erzeugung/Initialisierung über den Form Streaming Mechanismus erfolgt.

Aber du solltest dir's besser gleich abgewöhnen.

[FediDelPr]

Ich bin da weiterhin am Üben.

Die Klassendefinition habe ich geändert, so dass nun TEmailCoreObject ein
Nachkomme von TidIMAP4 ist.

Code:

TYPE
  TEmailCoreObject = CLASS(TidIMAP4)
  PRIVATE
    (* Private-Deklarationen *)
    OpenSSLHandler: TIdSSLIOHandlerSocketOpenSSL;
  PUBLIC
    (* Public-Deklarationen *)
    PROCEDURE OpenEmail(VAR IMAPClientExtd: TEmailCoreObject);
    PROCEDURE CloseEmail(VAR IMAPClientExtd: TEmailCoreObject);
  END;

Nun einige Fragen:
- Wenn ich eine Instanz von TEmailCoreObject erzeuge, ist dann das CREATE nur
für diese Instanz notwendig oder zusätzlich auch für TidIMAP4 ?
- Die Klasse TEmailCoreObject kommt auch als Parameter in den Methoden vor,
z.B. in OpenEmail(..). Ist das ein unzulässiger Schwanzbeisser oder geht das ?
- Wie kann ich ganz einfach feststellen, ob ein Objekt richtig erzeugt wurde ?
(am liebsten mit Debugger)

[hoika]

Hallo,
schreib ins Create ein inherited Create,
dann gilt das Create für beide.

Schwanzbeisser, ja
Warum das Objekt als Parameter an das gleiche Objekt/Klasse übergeben?

Initialisiertes Objekt erkennen?
Setze es auf NIL sonst erkennst du es nicht.