Zugriff auf Objekt in Klasse

[FediDelPr]

Ah danke noch, dann schau ich mal bei den Klassen-Methoden

[FediDelPr]

Gesetzt den Fall ich verzichte auf das Create im aufrufenden Modul,

Code:

VAR
  IMAPClientEx: TEmailCoreObject;
  ...

 BEGIN
   // IMAPClientEx := TEmailCoreObject.Create(nil);  --> kein Create
   IMAPClientEx.OpenEmail;
   ..

kann ich eine Methode trotzdem erreichen oder nicht ? Ist also der Einsprung trotzdem
garantiert oder geht der Aufruf quasi ins Leere (weil nicht definiert) ?
Beim Debugging war das erfolgreich. Zufall ?

[haentschman]

Moin...

Zitat:

kann ich eine Methode trotzdem erreichen oder nicht

Du kannst doch nicht ein Auto einsteigen (OpenEMail) wenn du es nicht produziert hast (Create)!
Zur dynamischen Verwendung einer Klasse/Objekt gehört immer ein Create/Free. Bei dieser Konstellation hast du die Wahl wann das Objekt im Speicher aufgenommen wird (Create) und wieder entfernt wird (Free).

Zitat:

Beim Debugging war das erfolgreich. Zufall ?

Wenn das so wäre, erzählst du uns nur die Hälfte. Bei diesen obigen Code, ohne Create, bekommst du definiv eine Zugriffsverletzung!

Zitat:

Weil das nur ein technisches Problem (endlicher Speicher) ist und nichts mit der eigentlichen Aufgabe zu tun hat.

Auch deine Main Form, und alle anderen automatisch erzeugten, liegen schon im Speicher. Besser wäre es wenn nur die Formulare erzeugt werden wenn sie gebraucht werden und wieder aus dem Speicher entfernt werden. Alle Forms haben ein Create/Free...nur macht das Delphi im Hintergrund.

Zitat:

versinkt in solchen technischen Details.

...das nennt man programmieren und nicht Klick Bunti.

Zitat:

Eine normale Variable muss man ja auch nicht zuerst kreiieren.

Auch für eine Variable wird Speicher reserviert...im Hintergrund.

Wie schon mehrfach gesagt:

Delphi-Quellcode:

type
  TEmailCoreObject = class(TidIMAP4)
  private
  public
    constructor Create(Owner: TComponent);
    destructor Destroy; override;
    procedure OpenEmail;
  end;


implementation

constructor TEmailCoreObject.Create(Owner: TComponent)
begin
  inherited Create(Owner) // immer erste Zeile -> Erzeugen Vorfahr TidIMAP4
  //
end;

destructor TEmailCoreObject.Destroy;
begin
  //
  inherited; // immer letzte Zeile
end;  
.
.
.
procedure TfoMain.Blubb;
var
  IMAPClientEx: TEmailCoreObject;

begin
  IMAPClientEx := TEmailCoreObject.Create(nil);
  try
    IMAPClientEx.OpenEmail;
  finally
    IMAPClientEx.Free;
  end;
end;

Stell den gesamten Code mal ein.

[hoika]

Hallo,
ich glaube der TE verwechselt Debuggen mit Compilieren.

Wenn Du ohne Create arbeiten willst,
Musst du die Klasse über den Delphi-Designer auf das DataModul packen.

Davon raten dir hier alle ab.
Jetzt musst du halt entscheiden.

[haentschman]

Zitat:

Musst du die Klasse über den Delphi-Designer auf das DataModul packen.

@TE: Zum Verständnis. Auch bei dieser Variante wird ein Create/Free ausgeführt...im Hintergrund. Das Objekt ist immer im Speicher, mit Create des DataModules, auch wenn es nicht benutzt wird!

Nochmal zu Klassenmethoden:
https://www.delphi-treff.de/tutorial...i-crashkurs/8/

Zitat:

Klassenmethoden

Es kann manchmal sinnvoll sein, dass man eine Methode nicht über die Instanz einer Klasse aufrufen möchte, sondern nur über die Klasse. So könnte man sich vorstellen, dass die Klasse „TgeomForm“ eine Methode „dimension“ besitzt, welche zurückgibt, welche Dimension die geometrischen Objekte besitzen, die durch diese Klasse dargestellt werden. Das Ergebnis dieser Methode wäre nicht abhängig von einer Instanz, sondern für die gesamte Klasse identisch.
Möchte man eine solche Methode haben, so leitet man sie bei der Deklaration mit dem Schlüsselwort „class“ ein.

type
TgeomForm = class
{...}
public
class function dimension : Integer;
end;

{...}

class function TgeomForm.dimension : Integer;
begin
result := 2;
end;

Selbstverständlich kann man in Klassenmehtoden nicht auf die Eigenschaften einer Klasse zuzugreifen, da diese nur existieren, wenn man mit Instanzen arbeitet!

PS: Der Tippfehler aus Seite kopiert.

Frage:
Wie oft wird das Objekt benutzt? Je nach Verwendung kann man das Objekt direkt vor OpenMail erzeugen und direkt wieder freigeben oder z.b. im constructor der Form oder der Logik Klasse erzeugen und am Ende (jeweiliger destuctor) wieder freigeben. Damit hat man das Objekt über die Lebensdauer der Form z.B. im Zugriff ohne ständig Create/Free.

[brechi]

Für deinen Fall kannst du auch einen singleton implementieren (oder eine globale variable mit initialization und finalization nutzen), aber auch ich rate dir davon ab...

[TurboMagic]

Zugriff auf nicht erzeugte Objektreferenzen wird eher zeitnah knallen!
Einfach nicht so gegen das Create sträuben!
Du kannst halt auch nicht in der Bibliothek ein Buch ausleihen ohne den Ausleihvorgang irgendwie zu registrieren...

Und was Exceptionbehandlung anbelangt: die ist eigentlich weniger aufdringlich als die klassische
Fehlerbehandlungsmethode.

Warum?

Weil man früher direkt nach jedem Aufruf der schief gehen konnte eine Statusvariable (in Turbo Pascal IOresult,
in SAP's ABAP Sy-Subrc) direkt abfragen musste und dann dort den Fehler gleich behandeln musste weil er sonst
nach dem nächsten Aufruf einer Routine die diese Fehlerbehandlung nutzt überschrieben ist.

Bei Exceptions kann man mitunter auch eine zentrale Behandlung irgendwo implementieren und alle Exceptions
laufen dort auf, egal woher die kommen. Man kann auch Fehler durch unterschiedliche Exception Klassen unterscheiden
und nur die behandeln, die man für relevant hält. Diese Klassen können dann auch zusätzliche Daten die Infos
zur Fehlerursache enthalten bekommen usw. ALles Dinge, die der klassische Ansatz nicht bietet.
Der lenkt vielstärker von der eigentlichen Aufgabe ab als so ein Create Aufruf...