Klassen Methoden

[Luckie]

Hallo.

Ich schreibe ja gerade an meinem Klassen Tutorial und da hätte ich mal eine Frage, die mir auch meine Bücher nicht beantworten können. Wie Funktionieren Klassen Methoden und wozu sind sie gut? Ein kleines Beispiel zum Verständnis wäre auch nicht schlecht.

Danke schon mal.

[Chewie]

Also die erste Frage ist einfach zu beantworten: Wie funktionieren Klassenmethoden?

Klassenmethoden sind Methoden, die nicht im Kontext eines Objektes ausgeführt werden. Eine Klassenmethode gehört zwar zu einer Klasse, kann aber nicht auf Felder und Methoden einer Instanz (@choose: eines Objekts ;)) zugreifen, da der Methode ja kein Objekt zugeordnet ist.

In Sprachen wie C# oder Java macht das ganze Konzept auch viel Sinn, denn dort gibt es auch Klassenfelder. Angenommen, ich habe eine Klasse, die ein Auto beschreibt, dann habe ich Objektfelder und -methoden, die ein konkretes Exemplar eines Autos beschreiben, und die Klasse selbst, die nun allgemeine Informartionen über das Auto darstellt, z.B. die Zahl der gebauten Autos. Dort gibt es dann z.B. auch eine Methode, um die Anzahl der gebauten Autos zu erhöhen. Hier ist jede Klasse auch quasi ein Objekt, vereinfacht gesagt.

In der DL, in der es leider keine Klassenfelder gibt, haben für m ich Klassenmethoden eigentlich nur Sinn gemacht, wenn ich mehrere autonome Prozeduren oder Funktionen hab, die keine gegenseitigen Abhängigkeiten haben, aber doch inhaltlich irgendwie zusammengehören. Die pack ich dann in eine Klasse, die Klasse dient hier aber nur als Container, so wie es die Unit bei normalen Prozeduren täte.

[sakura]

Zitat:

Zitat von Chewie

In der DL, in der es leider keine Klassenfelder gibt

Na ja, mit DL.NET hat sich das ja glücklicherweise geändert. ;-)

...:cat:...

[Luckie]

Zitat:

Zitat von Chewie

Klassenmethoden sind Methoden, die nicht im Kontext eines Objektes ausgeführt werden. Eine Klassenmethode gehört zwar zu einer Klasse, kann aber nicht auf Felder und Methoden einer Instanz (@choose: eines Objekts ;)) zugreifen, da der Methode ja kein Objekt zugeordnet ist.
[..]
die Klasse dient hier aber nur als Container, so wie es die Unit bei normalen Prozeduren täte.

Das dürfte wohl die essents deines Postings sein.

Dann hat also der Sinn von Klassen Methoden eigentlich durch ihre halbherzige Implementation von Borland ihren eigentlichen Sinn verloren? Denn wenn ich einen Container brauche, dann kann ich ja auch eine neue Unit nehmen.

[Chewie]

Zitat:

Zitat von sakura

Zitat:

Zitat von Chewie

In der DL, in der es leider keine Klassenfelder gibt

Na ja, mit DL.NET hat sich das ja glücklicherweise geändert. ;-)

...:cat:...

Echt? Hm, wird mal Zeit, dass es ne D8-Trial gibt, um mal zu auszuprobieren, was jetzt alles möglich ist :-D

[Chewie]

Zitat:

Zitat von Luckie

Dann hat also der Sinn von Klassen Methoden eigentlich durch ihre halbherzige Implementation von Borland ihren eigentlichen Sinn verloren? Denn wenn ich einen Container brauche, dann kann ich ja auch eine neue Unit nehmen.

Ihren Sinn ganz verloren haben sie meiner Ansicht nach nicht, aber ihre Möglichkeiten sind doch stark eingeschränkt.
Aber mit Sicherheit gibt es noch andere Einsatzzwecke,, die ich nicht kenne, bei denen Klassenmethoden ohne -felder Sinn machen.

[sakura]

Zitat:

Zitat von Chewie

Aber mit Sicherheit gibt es noch andere Einsatzzwecke,, die ich nicht kenne, bei denen Klassenmethoden ohne -felder Sinn machen.

Im Zweifel kann man ja die Klassenfelder innerhalb des Implementation-Teil als Variablen deklarieren ;-)

...:cat:...

[Luckie]

Zitat:

Zitat von sakura

Im Zweifel kann man ja die Klassenfelder innerhalb des Implementation-Teil als Variablen deklarieren ;-)

Stellen sich da nur bei mir die Fußnägel hoch? :gruebel:

[Chewie]

Zitat:

Zitat von Luckie

Zitat:

Zitat von sakura

Im Zweifel kann man ja die Klassenfelder innerhalb des Implementation-Teil als Variablen deklarieren ;-)

Stellen sich da nur bei mir die Fußnägel hoch? :gruebel:

Eine Möglichkeit ist es schon, besonders, wenn sich innerhalb eines Objektes sich ein Zeiger auf diese globale Variable als Klasseninstanz befindet, um wieder halbwegs OO-konform zu werden. Work-arounds sind oft schmutzig, aber manchmal muss die Drecksarbeit halt gemacht werden :zwinker:

[Luckie]

Zitat:

Zitat von Chewie

Work-arounds sind oft schmutzig, aber manchmal muss die Drecksarbeit halt gemacht werden :zwinker:

Wäre was für eine Signatur. ;)

[Chewie]

Zitat:

Zitat von sakura

Im Zweifel kann man ja die Klassenfelder innerhalb des Implementation-Teil als Variablen deklarieren ;-)

Das ist eigentlich als Work-around gar nicht so übel. Wenn man in der Klasse Felder deklariert, die auf die globalen Variablen zeigen, hat man fast Klassenfelder. Aber nur fast: In der Klassenmethode muss noch direkt auf die globalen Variablen zugegriffen werden:

Delphi-Quellcode:

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  ClassField1: Integer = 0;
  ClassField2: Boolean = false;

type
  TMyObjectWithClassFields = class(TObject)
  private
    FMyClassField1: PInteger;
    FMyClassField2: ^Boolean;
  public
    constructor Create;
    class procedure IncClassFields;
    procedure ShowValues;
  end;

var
  Form1: TForm1;
  myObject: TMyObjectWithClassFields;

implementation

{$R *.DFM}

{ TMyObjectWithClassFields }

constructor TMyObjectWithClassFields.Create;
begin
  FMyClassField1 := @ClassField1;
  FMyClassField2 := @ClassField2;
end;

class procedure TMyObjectWithClassFields.IncClassFields;
begin
  Inc(ClassField1);
  ClassField2 := not ClassField2;
end;

procedure TMyObjectWithClassFields.ShowValues;
var
  boolString: String;
begin
  if FMyClassField2^ then
    boolString := 'true'
  else
    boolString := 'false';
  ShowMessage('MyClassField1: ' + InttoStr(FMyClassField1^) + #13#10 +
              'MyClassField2: ' + boolString);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  myObject := TMyObjectWithClassFields.Create;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  myObject.Free;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  myObject.IncClassFields;
  myObject.ShowValues;
end;

end.

[DP-Maintenance]

Dieses Thema wurde von "Luckie" von "VCL-Komponenten und Controls" nach "Object-Pascal / Delphi-Language" verschoben.
Gehört nicht hier rein. :roll:

[negaH]

Hi

Die hier gegebene Erklärungen und Antworten sind meiner Meinung nach nicht ganz richtig.

1.) Klassemethoden arbeiten auf Klassen, statt wie bei Object methoden auf Instancen einer Klasse. Somit wird ihre Aufgabe klar unterschieden. Während Object Methoden auf lokale, Object-individuelle Daten zugreifen und diese dementsprechen OOP mäßig verwalten, verwalten Klassen Methoden die Eigenschaften ALLER Objecte mit gleichem Klassentyp im globalen Sinne.
2.) Sie sind NICHT überholt, ohne Klassenmethoden würde die RTTI, die TypInfos zu Objecten, somit die Grundlage zur OOP fehlen
3.) Borland hat hier mit dem Verzicht von Klassen Variablen Konsequenz gezeigt, und sch klar zu N.Wirth's Ideen bekannt. Ganz im Gegensatz zu C usw. Denn wenn eine Klasse eine fixierte und konzeptionelle Definition der OOP ist dann darf sie auch keine zur Laufzeit variablen Elemente enthalten. Im Falle des Beispieles mit der Anzahl der produzierten Autos wäre es OOP richtiger, dazu ein neues Object zu definieren das die Fabrik also solches beschreibt. Dieses verwaltet dann den Produktionszähler. Nun wird auch im OOP Sinne sichtbar warum man dies so machen sollte. Auf Klassenebene kann es nur EINE TFabrik geben, auf Object-Instance Ebene aber ganz viele solcher TFarbik'en.
Somit sind Klassen und Klassen Methoden die Demarkationslinie zwischen der Laufzeit und der Designzeit in der OOP. Ohne Klassenmethoden würden also alle Features der IDE, der Designzeit und der partiellen Nutzbarkeit der Typinfos zur Laufzeit (zb. Typsicherheit), in der OOP garnicht möglich sein. Damit stellen Klassenmethoden ein OOP-Interface zur Laufzeit eines Programmes dar, das es dem Programmierer ermöglicht auf die zur Designzeit gemachten konzeptionellen Vorgaben zuzugreifen.
4.) statische Klassen-Konstanten sind nichts anderes als Klassen-Methoden mit Rückgabewerten, zB. .ClassName ist eine solche statische Klassen-Konstante. D.h. per OOP Definition kann ganz leicht über Klassen-Methoden eine Klassenkonstante definiert werden. Deren Rückgabewert untescheidet sich dann von Klassentyp zu Klassentyp, deren Scope ist aber meistens für alle Klassen gleich. D.h. .ClassName ist zb. eine virtuelle Klassen Methode, die in jeder Klasse als gemeinsamme Schnittstelle uniform vorhanden ist. Deren Rückgabewert ist aber eindeutig zum jeweiligen Klassentyp. Somit stellen Klassen-Konstanten keine Verletzung des OOP Konzeptes dar, und Klassen-Methoden sind das korrekte und notwendige OOP Mittel.
5.) variable Klassen-Variablen kann man so umsetzen:

Delphi-Quellcode:

type
  TMyClass = class
  private
    class function GetCounter: Integer;
    class procedure SetCounter(Value: Integer);
  public
    property Counter: Integer read GetCounter write SetCounter;
  end;

implementation

var
  FCounter: Integer = 0;

class function TMyClass.GetCounter: Integer;
begin
  Result := FCounter;
end;

class procedure TMyClass.SetCounter(Value: Integer);
begin
  FCounter := Value;
end;

Betrachtet man die "Unit" selber als "Klasse", mit den Zugriffsbezeichnern "interface" und "implementation" so wäre die lokale Variable FCounter absolut im Sinne von guter OOP ! Nicht anders funktioniert auch .NET, es MUSS irgendwo IMMER lokale und globale Variablen in einer Anwendung geben. Sie sind also NICHT schlechter Programmierstil an sich.

Gruß Hagen

[negaH]

ps: es gibt in fakt nur EINE einzigste wirklich sinnvolle Anwendung für Klassen-Variablen die ich kenne. Nämlich die Verwaltung der aktuelle allozierten Object-Instance zu dem jeweiligen Klassentyp.

In C hat man Klassenvariablen eingeführt damit laufzeit-dynamische Klassen konstruiert werden können. D.h. man kann über Klasenvariablen zur Entwurfzeit bestimmen das man zur Laufzeit zb. die Klassenhierarchie ändern kann. Allerdings WIDER-spricht das dem strikten Konzept von N.Wirth, der davan ausgeht das ein OOP Konzept und deren Objecthierarchien eine zur Laufzeit fixierte Rahmenbedingung darstellen MUSS, eine Schnittselle eben für andere Programmierer. Denn, was soll dabei herauskommen, wenn man eine Schnittstelle definiert die jederzeit zur Laufzeit polymorph ansich ist. Dies widerspricht der OOP. In C++ werden in diesem Zusammenhang oft die Klassen-Templates benutzt, nun wir wissen ja was wir von Templates zu halten haben :)

Ok, im Falle von JAVA sind solche Konzepte schon wieder sinnvoller, wobei aber nicht unbedingt erstrebenswert. JAVA ist immer eine interpretierende Sprache, somit kann über Klassenvariablen strukturiert auf den Interpretations-Prozess des Interpreters zur Laufzeit Einfluß genommen werden.

Gruß Hagen

[Luckie]

Hm. Eventuell lasse ich das Kapitel erstmal raus, verstehe ich ja selber noch nicht so. Und man muss sich ja Optionen für ein Update offen alten. ;)

[Bernd Ua]

da möchte doch auch nochmal meinen Senf beisteuern

ein netter Weg um Daten auf Klassenebene zu halten und auf Variablen auf Unitebene zu verzichten
sind typisierte Konstanten auf Ebene einer Klassenmethode. So implementiert ModelMaker zB den Singleton Pattern.

@luckie: Klassenmethode weglassen, wäre schade drum, dann hört dein OOP Tutorial da auf wo es interessant wird.
Klassenmethoden sind IMHO ein schönes Mittel für die Kapselung und natürlich für die RTTI.
Probier doch mal das aus auf einem Formular mit Button und Listbox aus:

Delphi-Quellcode:

// alle Vorfahren ausgaben
procedure TForm1.Button1Click(Sender: TObject);
var
  aClass : TClass;
begin
  aClass := Sender.ClassType;
  while Assigned(aClass) do
    begin
      Listbox1.Items.Add(aClass.Classname);
      aClass := aClass.ClassParent;
    end;
end;

Bernd

[Luckie]

Zitat:

Zitat von Bernd Ua

@luckie: Klassenmethode weglassen, wäre schade drum, dann hört dein OOP Tutorial da auf wo es interessant wird.
Klassenmethoden sind IMHO ein schönes Mittel für die Kapselung und natürlich für die RTTI.
Probier doch mal das aus auf einem Formular mit Button und Listbox aus:

Delphi-Quellcode:

// alle Vorfahren ausgaben
procedure TForm1.Button1Click(Sender: TObject);
var
  aClass : TClass;
begin
  aClass := Sender.ClassType;
  while Assigned(aClass) do
    begin
      Listbox1.Items.Add(aClass.Classname);
      aClass := aClass.ClassParent;
    end;
end;

LOL. Das ist das Beispie aus der Delphi-Hilfe oder?

Ja, würde ich ja auch gerne mit reinnehmen, nur fehlt mir irgendwie noch immer das Grundlegende und das tiefere Verständnis über Klassenmethoden. Daran hängt es eben noch im Moment.

[edit]Mich würde es auch nicht stören, wenn jemand anders das Kapitel beisteuern würde.[/edit]

[Bernd Ua]

Zitat:

LOL. Das ist das Beispie aus der Delphi-Hilfe oder?

weiss nich - kann sein, glaube aber nicht. Ich nehms gerne in meinen Trainings
um die Unterschiede von Klassenmethoden und normalen Methdoen deutlich zu machen

Zitat:

Ja, würde ich ja auch gerne mit reinnehmen, nur fehlt mir irgendwie noch immer das Grundlegende und das tiefere Verständnis über Klassenmethoden.

Neben tollen Sachen, die man mit dem Typ TClass bzw eigenen Klassenreferenztypen machen kann
dienen Klassenmethoden vor allem zur Strukturierung und Kapselung.
( Kombiniert mit virtuellen Konstruktoren bildet der Klassenreferenztyp das Rückrat des
ganzen Streamimg Systems der Delphi-Formulare. )

Nimm beispielsweise einen Dateneingabedialog, den Du programmieren willst.
Wenn du prozedural rangehst, baust du dafür vielleicht (bzw hoffentlich)
in der Unit eine Funktion wie folgt :

Delphi-Quellcode:

type
  TForm2 = class(TForm)
    Button1: TButton;
  private
  public
  end;

var
  Form2: TForm2;

function GetData (out Data : TSomeData): Boolean;

implementation

{$R *.dfm}

function GetData (out Data : TSomeData): Boolean;
begin
  with TFrmData.Create(nil) do
    try
      Result := ShowModal=mrOk;
      if Result then
        Data := ...
    finally
       Free;
    end;
end;

Genausogut kannst Du aber sagen, was soll die sch.. Funktion, die macht doch ohne den Dialog keinen Sinn
und fasst die Funktion und die Klasse mittels Klassenmethdoe zu einer logischen Einheit zusammen :

Delphi-Quellcode:

type
  TForm2 = class(TForm)
    Button1: TButton;
  private
  public
    class function TForm2.GetData (out Data : TSomeData): Boolean;
  end;

implementation

{$R *.dfm}

class function TForm2.GetData (out Data : TSomeData): Boolean;
begin
  with TFrmData.Create(nil) do
    try
      Result := ShowModal=mrOk;
      if Result then
        Data := ...
    finally
       Free;
    end;
end;

Von aussen rufts Du die Klassenmethode dann wie folgt auf

Delphi-Quellcode:

if TForm2.GetData(...) then

Hättest Du stattdessen GetDat zu einer normalen Methode degradiert,
müsstest Du den Dialog auch von aussen erzeugen - was weder gut gekapselt noch besonders elegant ist.

Die freistehende Funktion ginge natürlich auch, nur in "reinen" OOP-Sprachen gibt es sowas halt nicht.
( vieles was in Delphi als Funktionssammlung in Units zusammengefasst ist, findet sich in Java als
Klasse, die ausschliesslich Klassenmethoden enthält und nie instanziiert wird )

Bernd

[Luckie]

Diskutiert das ruhig noch etwas weiter. Ich lese fleißig mit, in der Hoffnung, dass es irgendwan nmal klick macht. :?

Danke aber schon mal allen für ihre hilfreichen Ausführungen.

[Bernd Ua]

Eigentlich war geplant, das es bei obigen Beispiel bei Dir klick macht :)

[Luckie]

Ähm. :oops: Also ich muss mir das noch etwas genauer ankucken, nachvollziehen und verinnerlichen. Mal sehen, ich melde mich dann wieder. ;)

[stoxx]

Zitat:

Zitat von Luckie

Diskutiert das ruhig noch etwas weiter. Ich lese fleißig mit, in der Hoffnung, dass es irgendwan nmal klick macht. :?

Danke aber schon mal allen für ihre hilfreichen Ausführungen.

und wie wärs mit diesem Beispiel ?
das create fehlt :-)
wichtige Einschränkung natürlich, dass auf keine Felder einer Instanz (eines Objectes) zugegriffen werden darf in der Klassenmethode. DA natürlich das object noch nicht createt ist.

Code:

procedure TForm1.Button1Click(Sender: TObject);
begin
  caption := Tedit.Classname;
end;

viele Grüße
stoxx

[Luckie]

So, Bernd. Ich habe deinen Cod emal in ein funktionierendes Beispiel umgesetzt:

Delphi-Quellcode:

type
  TSomeData = record
    FData: String[255];
  end;

type
  TForm1 = class(TForm)
    Label1: TLabel;
    Label2: TLabel;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    Data: TSomeData;
    class function GetData (out Data : TSomeData): Boolean;
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

uses
  Unit2;

class function TForm1.GetData(out Data: TSomeData): Boolean;
begin
  with TForm2.Create(nil) do
  begin
    Result := ShowModal = mrOK;
    Data.FData := Edit1.Text;
    Form1.Label2.Caption := Data.FData;
  end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  GetData(Data);
end;

Form2 besteht nur aus einem Edit zur Eingabe und zwei Buttons, die entweder mrOK oder mrCancel setzen.

[stoxx]

Zitat:

Zitat von Luckie

So, Bernd. Ich habe deinen Cod emal in ein funktionierendes Beispiel umgesetzt:

ähm, Luckie, welchen Sinn hat das jetzt *g* ?? :gruebel:

[Luckie]

Zitat:

Zitat von stoxx

ähm, Luckie, welchen Sinn hat das jetzt *g* ?? :gruebel:

Genau das ist wohl der Knackpunkt, wenn ich den habe, dann bin ich schon mal einen großen Schritt weiter. ;)

[NicoDE]

Zitat:

Zitat von Luckie

So, Bernd. Ich habe deinen Cod emal in ein funktionierendes Beispiel umgesetzt

Eigentlich verfehlt Dein Beispiel den eigentlichen Sinn. Wozu hat TForm1 eine Klassenmethode? TForm2 sollte die Klassenmethode implementieren, damit TForm1 _nicht_ wissen muss, wie die Daten geholt werden und damit TForm1 _keine_ Instanz von TForm2 erzeugen muss um das gewünschte Result zu erhalten.

[Luckie]

Habe ich auch gerade gemerkt, dass das nicht viel Sinn macht. Ich probiere es mal anders rum.

Äh, nee wie jetzt? Wie kommt denn Form1 an die Daten ran, die ich in Form2 eingebe?

[Chewie]

Der Sinn ist doch ganz einfach zu erschließen.
GetData ist zwar eine autonome Funktion, ohne Aufrufe anderer Funktionen und ohne Benutzung globaler Variablen, aber sie macht doch nur Sinn, wenn sie im Zusammenhang mit TForm2 aufgerufen wird.
Durch die Klassenmethode ist GetData an TForm2 gebunden, TForm2 dient hier u.a als eine Art Container.

[Bernd Ua]

@Luckie : Bin ja gespannt was Du in Deinem Tutorial zum Thema Abstraktion sagst :(
Ich prökel Dir mal ein Beispiel zusammen ... kommt dann gleich

[Luckie]

Eine Beta Version kannst du dir schon hier ankucken: http://www.luckie-online.de/files/beta-area/

Aber der :( Smily läßt mich jetzt doch etwas zweifeln. :gruebel:

[Bernd Ua]

Hier ist das Beispiel mit drei Versionen von Dateneingabeformularen ( völlig Sch.., mit Funktion und Klassenfunktion)

Bernd

[Bernd Ua]

Hi Luckie, hab Deine beta mal überflogen und schon die ersten Bugs gefunden.
Muss jetzt aber leider mal Weile ins Offline verschwinden ...

Bernd

[fkerber]

Hi!

Ich bin so frei mich hier mal mit meinem Unverständniss einzumischen.

Habe mir mal das oben gepostete Beispiel angeschaut und stehe jetzt etwas ratlos da.

Den Unterschied zwischen Mistform und den anderen erkenne ich und sehe ich ein.

Aber wo liegt der Unterschied zwischen den beiden anderen und der Sinn?
Der Code ist doch fast genau der selbe oder? Nur das Wörtchen "class" davor und der etwas geänderte Aufruf.
Wo liegt der Sinn in dem Ganzen?

Ciao fkerber

[Luckie]

Zitat:

Zitat von Bernd Ua

Hi Luckie, hab Deine beta mal überflogen und schon die ersten Bugs gefunden.

Ist auch erstmal nur eine Beta. Wäre nett, wenn du mir die Bugs nennen könntest, denn ich will auf keinen Fall Mist verbreiten. Allerdings so schwerwiegend können sie nicht sein, da ich die meine Quellen der Handbuchsatz und "Delphi in a nutshell" sind. :?

[Bernd Ua]

ok einen letzten Post noch aber dann kommt meine Frau dran :oops:

Der Sinn liegt in diesem Fall darin, Schnittstellenroutine und Klasse, die von dieser verwendet wird
zu einer logischen Einheit zusammenfassen.
Die Zugehörigkeit zur Klasse macht den Kontext der Funktion deutlich
erfordert aber im Gegensatz normalen Methode keine Instanziierung von Aussen.
Sie dient hier lediglich der Kapselung und Strukturierung des Codes
(ich mag ja den Ausdruck selbstdokumentierender Quelltext ja fast nicht in den Mund
nehmen, aber es geht in die Richtung )

Java/C++ oder C# Entwickler könnten jedenfalls mit der Klassenmethoden Variante mehr anfangen,
die kenne es nicht anders ( sie nennen es nur anders , nämlich statische Methoden)

Bernd

[Luckie]

Ja. Klar. Dank dir. Viel Spaß mit der Klasse TMeineFrau. ;)

Sehe ich das richtig, dass der zweite und dritte Aufruf identisch sind? Und der dritte sich nur darin unterscheidet, dass durch das Davorsetzten des Formularnamens die Lesbarkeit erhöht wird?

[Chewie]

Zitat:

Zitat von Luckie

Äh, nee wie jetzt? Wie kommt denn Form1 an die Daten ran, die ich in Form2 eingebe?

Also: TForm2 hat die Klassenmethode GetData mit dem Ausgabeparameter SomeData. Nun rufst du die Klassenmethode GetData von TForm2 auf. Diese erzeugt das Dialogfeld und speichert die Benutzerangaben in den Ausgebeparameter.
Klar?

[Luckie]

@Chewie: hat sich erledigt. Nico hat mir ein einfaches Beispiel gegeben und Bernd Ua eine gute Gegenüberstellung.

So, aktuelle beta Version hochgeladen, inklusive der Demos.