Hallo,
als Delphi-Anfänger habe ich zur Zeit leider viele offene Fragen rund um TEdit:

1. Ist es eigentlich ein "guter" Programmierstil aus anderen Formularen (z.B. Form 1) auf eine Eingabe in Form2 mit der folgenden Art zurückzugreifen: Unit_x.Form_x.Edit.Text ? Wenn in einem Eingabeformular da sehr viele TEdits habe und die Werte daraus in anderen Units für Berechnungen verwende scheint mir das doch eher ziemlich mies, oder nicht? Auf der anderen Seite kann ich mir so gaaaaanz viele Variabeln sparen, weil ich ja immer direkt auf die Edit.Text 'te zurückgreife.

2. Angenommen ich würde mich dann dafür entscheiden die Werte aus meinem Eingabe Formular(mit den TEdits eben) alle in Variablen zu speichern, die ich mir unter "public" zunächst deklariere. Welches Ereignis müsste ich dann auswählen um das zu machen? Ich meine, es gibt kein "Bestätigen-Button" in meinem Formular und ich möchte nicht für jedes Edit-Feld eine "onchange" Prozedur um den Wert / Text von TEdit in meine Variable zu übertragen. Sondern eine Prozedur die alle Werte aufnimmt und aktualisiert wenn ich nur einen x-beliebigen Wert in einem der TEdit-Felder ändere (es sind default Werte voreingestellt).

3. Eine letze und dritte Frage wäre dann noch wie man es bewerkstelligt dass eine Berechnung immer dann ausgeführt wird wenn ein Wert in einer ComboBox UND einem TEdit Feld (auf dem gleichen Formular / Unit) gegeben ist. Sowohl die ComboBox als auch Edit werden ja leer initialisiert und das sollen sie hier auch. Egal in welcher Reihenfolge der Benutzer nun die Werte in ComboBox und TEdit ändert möchte ich das bei jeder Änderung meine Rechnung durchgeführt wird. Muss ich dazu etwa eine onchange Prozedur für Edit und die Box aufsetzten, die dann auf die gleiche Rechnung verweisen? Das wäre ja super umständlich und geht bestimmt einfacher, wenn man weiß wie...

Sry, für die dummen Fragen ^_^.
Gruß,

Dash Rendar

Hallo,

Zitat von DashRendar:

1. Ist es eigentlich ein "guter" Programmierstil aus anderen Formularen (z.B. Form 1) auf eine Eingabe in Form2 mit der folgenden Art zurückzugreifen: Unit_x.Form_x.Edit.Text ? Wenn in einem Eingabeformular da sehr viele TEdits habe und die Werte daraus in anderen Units für Berechnungen verwende scheint mir das doch eher ziemlich mies, oder nicht? Auf der anderen Seite kann ich mir so gaaaaanz viele Variabeln sparen, weil ich ja immer direkt auf die Edit.Text 'te zurückgreife.

Guter Programmierstil ist das nicht. Wenn Du wirklich OOP programmierst, dann erzeugst Du Properties in Deinen Forms und grifst über diese auf die Ergebnisse zu.

Zitat von DashRendar:

2. Angenommen ich würde mich dann dafür entscheiden die Werte aus meinem Eingabe Formular(mit den TEdits eben) alle in Variablen zu speichern, die ich mir unter "public" zunächst deklariere. Welches Ereignis müsste ich dann auswählen um das zu machen? Ich meine, es gibt kein "Bestätigen-Button" in meinem Formular und ich möchte nicht für jedes Edit-Feld eine "onchange" Prozedur um den Wert / Text von TEdit in meine Variable zu übertragen. Sondern eine Prozedur die alle Werte aufnimmt und aktualisiert wenn ich nur einen x-beliebigen Wert in einem der TEdit-Felder ändere (es sind default Werte voreingestellt).

Variablen im Public-Bereich sind wo immer möglich zu vermeiden und durch Properties zu erstzen. Du solltest also Properties erstellen und im Getter das jeweilige Edit abfragen. Dadurch benötigst Du auch keinen Ereignishandler, da das Edit immer dann abgefragt wird, wenn Du den Inhalt benötigst.

Zitat von DashRendar:

3. Eine letze und dritte Frage wäre dann noch wie man es bewerkstelligt dass eine Berechnung immer dann ausgeführt wird wenn ein Wert in einer ComboBox UND einem TEdit Feld (auf dem gleichen Formular / Unit) gegeben ist. Sowohl die ComboBox als auch Edit werden ja leer initialisiert und das sollen sie hier auch. Egal in welcher Reihenfolge der Benutzer nun die Werte in ComboBox und TEdit ändert möchte ich das bei jeder Änderung meine Rechnung durchgeführt wird. Muss ich dazu etwa eine onchange Prozedur für Edit und die Box aufsetzten, die dann auf die gleiche Rechnung verweisen? Das wäre ja super umständlich und geht bestimmt einfacher, wenn man weiß wie...

Du kannst beiden Controls den selben OnChange-Handler zuweisen. Der könnte dann z. B. so aussehen:

markieren

Delphi-Quellcode:

procedure TForm1.OnChange(Sender: TObject);
begin
  if (Edit1.Text <> '') and (ComboBox1.Text <> '') then
    Berechne(Edit1.Text, ComboBox1.Text);
end;

Beachte, dass ich die Berechnung nicht im Ereignishandler durchführe, sondern eine eigene Methode aufrufe. Man sollte nämlich möglichst immer Oberfläche und Programmlogik voneinander trennen.

Zitat von DashRendar:

Sry, für die dummen Fragen ^_^.

Hey, wer nicht fragt, bekommt auch keine Antworten .

Gruß
xaromz

Danke für Deine Antwort. Allerdings verstehe ich nur die Antwort auf meine dritte Frage. Mit dem "getter" und properties habe ich zumind. in Delphi noch nie gearbeitet und mir ist auch nicht ganz klar wie man über die Eigenschaften einer Klasse das Ein-, Auslesen und "interne" speichern von mehreren TEdit-Werten regelt. Ja, ich habe auch in der Borland-Hilfe zum "getter" geguckt, aber aus den Beispieln / Erklärungen die da stehen werde ich auch nicht schlau.
Gibt es also auch eine nicht-OOP Lösung für Frage 2 und 3? Im übrigen hatte ich ja nicht vor globale Variablen zu deklarieren, sondern die Variabeln im public-Teil des Interfaces zu deklarieren, mit einer Trennung von Oberfläche und Programmlogik wärs dann allerdings schon vorbei.

Hallo,

Zitat von DashRendar:

Danke für Deine Antwort. Allerdings verstehe ich nur die Antwort auf meine dritte Frage. Mit dem "getter" und properties habe ich zumind. in Delphi noch nie gearbeitet und mir ist auch nicht ganz klar wie man über die Eigenschaften einer Klasse das Ein-, Auslesen und "interne" speichern von mehreren TEdit-Werten regelt. Ja, ich habe auch in der Borland-Hilfe zum "getter" geguckt, aber aus den Beispieln / Erklärungen die da stehen werde ich auch nicht schlau.

Wie Du die Properties einsetzt, hängt davon ab, wie Dein Formular aussieht.
Ich werde mal ein Beispiel skizzieren. Dabei geht es um die Eingabe einer Adresse. Sämtliche Felder lassen sich lesen, der Name zusätzlich ändern:

zusammenfalten · markieren

Delphi-Quellcode:

interface

type
  TForm1 = class(TForm)
    UserNameEdit: TEdit;
    StreetEdit: TEdit;
    PostalEdit: TEdit;
    CityEdit: TEdit;
    TelephoneEdit: TEdit;
  private
    function GetUserName: String;
    function GetStreet: String;
    function GetCity: String;
    function GetQualifiedCity: String;
    function GetTelephone: String;
    procedure SetUserName(const Value: String);
  public
    property UserName: String read GetUserName write SetUserName;
    property Street: String read GetStreet;
    property City: String read GetCity;
    property QualifiedCity: String read GetQualifiedCity;
    property Telephone: String read GetTelephone;
  end;

implementation

function TForm1.GetUserName: String;
begin
  Result := UserNameEdit.Text;
end;

function TForm1.GetStreet: String;
begin
  Result := StreetEdit.Text;
end;

function TForm1.GetCity: String;
begin
  Result := CityEdit.Text;
end;

function TForm1.GetQualifiedCity: String;
begin
  // z. B. Postleitzahl und Stadt zurückgeben
  Result := PostalEdit + '-' + CityEdit.Text;
end;

function TForm1.GetTelephone: String;
begin
  Result := TelephoneEdit.Text;
end;

procedure TForm1.SetUserName(const Value: String);
begin
  UserNameEdit.Text := Value;
end;

Jetzt kannst Du auf die Eingaben ganz einfach zugreifen:

markieren

Delphi-Quellcode:

//Lesen
Name := Form1.UserName;
Street := Form1.Street;
City := Form1.City;
Telephone := Form1.Telephone;

//Schreiben
Form1.UserName := 'Schmidt';

Wid Du siehst, musst Du außerhalb des Formulars nicht wissen, wie die Edits heißen. Du musst nicht einmal wissen, ob es überhaupt welche gibt.
In den Getter- und Setter-Methoden kannst Du außerdem noch zusätzliche Prüfungen einbauen oder die Ausgabe verändern (wie z. B. bei GetQualifiedCity).

Zitat von DashRendar:

Gibt es also auch eine nicht-OOP Lösung für Frage 2 und 3? Im übrigen hatte ich ja nicht vor globale Variablen zu deklarieren, sondern die Variabeln im public-Teil des Interfaces zu deklarieren, mit einer Trennung von Oberfläche und Programmlogik wärs dann allerdings schon vorbei.

Es gibt natürlich immer eine nicht-OOP-Lösung. Aber sowas werde ich hier nicht verbreiten. Ich will Dich ja nicht versauen .
Wie ich oben schon schrieb, auch im Public-Teil sollten Variablen vermieden werden. Du wirst in der gesamten VCL keinen Fall erleben, in dem eine Variable als Public deklariert wäre.

Gruß
xaromz

Erstmal vielen Dank das Du Dir dafür bei diesem tollen Wetter (zumind. hier im Norden^^) am Sonntag die Zeit für soviel Text genommen hast. Das Beispiel habe ich verstanden und hat mir auf jeden Fall weiter geholfen. Allerdings hat mein Eingabeformular etwas mehr als 50-Integer Werte, so dass das Ganze durch die properties recht aufwendig wird, aber was solls.

So sieht das Formular aus:
--> siehe Anhang <--

Dies soll nur eine Rechen- / Simulations-Anwendung für ein existierendes Spiel werden, um Himmels Willen kein Spiel selbst. Um mich vor Ärger zu schützen verweise ich jedoch einfach darauf das die Rechte und Namen für das Spiel bei Tim Wisseman liegen.

Ich versuche mich ja immer nur vor OOP zu drücken weil ich das schwieriger finde

Gruß und Dank,
DashRendar

Hallo,

Zitat von DashRendar:

Erstmal vielen Dank das Du Dir dafür bei diesem tollen Wetter (zumind. hier im Norden^^) am Sonntag die Zeit für soviel Text genommen hast. Das Beispiel habe ich verstanden und hat mir auf jeden Fall weiter geholfen.

Hier im Süden ist das Wetter auch ganz gut. Freut mich, wenn ich Dir helfen konnte.

Zitat von DashRendar:

Allerdings hat mein Eingabeformular etwas mehr als 50-Integer Werte, so dass das Ganze durch die properties recht aufwendig wird, aber was solls.

So sieht das Formular aus: ...
Dies soll nur eine Rechen- / Simulations-Anwendung für ein existierendes Spiel werden, um Himmels Willen kein Spiel selbst. Um mich vor Ärger zu schützen verweise ich jedoch einfach darauf das die Rechte und Namen für das Spiel bei Tim Wisseman liegen.

Wenn ich mir Dein Formular ansehe, würde ich das sowieso anders regeln. Du hast hier ja Gruppen von Eingaben, was man schön an den Groupboxen sieht. Du könntest also für die einzelnen Gruppen Records (oder Klassen) anlegen, die Du dann befüllst. Damit hast Du auch eine logische Gruppierung im Programm und nicht nur eine optische. Falls Du die Werte nur benötigst, nachdem das gesamte Formular ausgefüllt wurde, kannst Du (z. B. beim Schließen des Formulars) die Records/Klassen mit den Werten befüllen und diese über Properties zur Verfügung stellen.
Das ist zwar etwas mehr Aufwand (insbesondere muss man viel tippen), aber es lohnt sich. Du kannst nämlich den Dialog einfach verwenden, ohne Dich um die Interna kümmern zu müssen, was insbesondere nach einigen Monaten praktisch ist, weil man inzwischen wieder alles vergessen hat .

Zitat von DashRendar:

Ich versuche mich ja immer nur vor OOP zu drücken weil ich das schwieriger finde

Wenn man das System verstanden hat, ist es eigentlich ganz einfach. Und die Vorteile (Wiederverwendbarkeit, Wartbarkeit, Übersichtlichkeit...) überwiegen dann doch ziemlich stark.

Ich würde Dich noch bitten, das Bild als Anhang in Deinen Beitrag zu stecken. Sonst ist es möglicherweise irgendwann weg, und dann wundert sich jemand, der den Beitrag liest. Über Deinem Beitrag hast Du ja rechts den Button "Edit".

Gruß
xaromz

Das mit den records klingt nicht schlecht . Ich werde das im Laufe der Woche mal ausprobieren.
Damit sind die Fragen für mich beantwortet.

Gruß,
DashRendar