Prozeduren vom anderen Formular aus aufrufen

[Teesäufer]

Hallo zusammen,

ich habe folgendes Problem: Ich hatte bisher ein Formular mit einem Start-Button. Da hat alles wunderbar funktioniert. Mir wurde bewusst, dass das Formular zu viele Elemente enthielt. Ein Großteil sollte in ein vorgelagertes Formular verschoben werden, u. a. auch die Start-Funktion. Also habe ich eine Prozedur geschrieben, die fast identisch war mit der Button1Click, nur dass sie Eingabeparameter enthielt. Im Grunde genommen funktionierte auch alles. Leider muss ich jetzt vor alle Formularelemente (Label1 usw.) den Formularname schreiben.

Kann man das nicht irgendwie einfacher haben?

[Redeemer]

Wenn du (viele) Sachen in einem anderen Formular machst, gehört dein Code schlichtweg in das Formular und nicht in ein anderes. Der Zugriff auf die automatisch generierte globale Variable mit dem Formularnamen (z.B. Form1) ist ohnehin verpönt.

Oder hast du eine Klassen- oder eine Nur-implementation -Methode geschrieben und kannst jetzt nicht mehr auf Self zugreifen?

with do

[Teesäufer]

Zitat von Redeemer:

Wenn du (viele) Sachen in einem anderen Formular machst, gehört dein Code schlichtweg in das Formular und nicht in ein anderes.

Ich möchte ein Formular, in dem ich ein Training einstelle und ein Formular, in dem das Training stattfindet.

[DeddyH]

Worauf Redeemer hinauswill: es ist schlechter Stil, aus einem Formular heraus auf Komponenten eines anderen Formulars zuzugreifen. Angenommen, Du hast ein Eingabeformular für einen Namen in einer Formklasse "TEingabeForm". Aus dem Hauptformular heraus möchtest Du jetzt den Namen ändern. Da gibt es z.B. folgende Möglichkeit:

Delphi-Quellcode:

procedure THauptForm.EditName;
begin
  EingabeForm.EditName.Text := FName;
  if EingabeForm.ShowModal = mrOK then
    FName := EingabeForm.EditName.Text;
end;

So weit, so gut, aber wenn Du plötzlich auf die Idee kommst, statt eines Edits eine ComboBox mit einer Auswahlliste zu verwenden, muss die ganze Logik für das Eingabeformular im Hauptformular geändert werden. Schön ist anders. Das kann man beispielsweise umgehen, indem man dem Eingabeformular eine Eigenschaft spendiert.

Delphi-Quellcode:

type
  TEingabeForm = class(TForm)
    ...
  private
    function GetUserName: string;
    procedure SetUserName(const Value: string);
    ...
  public
    property UserName: string read GetUserName write SetUserName;
    ...
  end;

...

function TEingabeForm.GetUserName: string;
begin
  Result := EditName.Text;
end;

procedure TEingabeForm.SetUserName(const Value: string);
begin
  EditName.Text := Value;
end;

Im Hauptformular sieht der Code dann so aus:

Delphi-Quellcode:

procedure THauptForm.EditName;
begin
  EingabeForm.UserName := FName;
  if EingabeForm.ShowModal = mrOK then
    FName := EingabeForm.UserName;
end;

Wie gesagt, solltest Du jetzt auf eine ComboBox umsteigen, musst Du den Code (sprich: Getter und Setter) nur im EingabeFormular ändern, also da, wo es hingehört, im Hauptformular ändert sich nichts.

[Redeemer]

Ich bezog mich eher auf Spagetticode, den er hier mit großer Wahrscheinlichkeit haben wird.

Normalerweise würde man eine Unit erstellen, die ein Datenmodell (Klasse, Verbund) mit in deinem Fall dem Namen TTraining enthält, das zunächst einmal nur aus Feldern besteht. Eine Form erstellt/füllt es, die andere lädt/zeigt es. Mindestens fürs Laden gibt es eine public-Methode im Hauptformular (z.B. SetTraining, LadeTraining). Dem Modell kann man dann Methoden hinzufügen, z.B. das Training in eine Datei zu speichern oder zu laden. Das geht seit vielen Jahren (D2009?) auch bei Verbünden und nicht nur bei Klassen.

[TurboMagic]

Ja, das wäre auch meine Frage: ist die geschäftslogik hier vom GUI getrennt?
Falls nein wäre das die gelegenheit damit wie vorgeschlagen anzufangen. Geschäftslogik
in eigene Klasse in eigener Unit auslagern. Die Unit können dann beide einbinden und man
übergibt halt die Objektreferenz der Geschäftslogik and das andere Formular.