UserInterface-Klasse

[cltom]

Hallo,

für einen wiederkehrenden Block von Eingabewerten würde ich gern den Transfer der UI-Elemente ins Objekt als eigene Klasse auslagern, also sinngemäß:

Delphi-Quellcode:

type
  TDataClass = Class(TObject)
        
    public
      ValueA: Integer;
      ValueB: string;

  end;

type
  TTransferClass = Class(TObject)
    
    public
      procedure GetValues(TargetContainer: TWinControl; MyObject: TDataClass);

  end;


Implementation

  procedure TTransferClass.GetValues(TargetContainer: TWinControl; MyObject: TDataClass);
  begin
    TryStrToInt(TargetContainer.edt_ValueA.Text, MyObject.ValueA);
    MyObject.ValueB := TargetContainer.edt_ValueB.Text;
  end;

Das geht natürlich so nicht, weil die Edit-Felder hier ja nicht bekannt sind, die liegen ja am TargetContainer (oder sogar auch nicht).

Eine Variante wäre es, die Controls erst hier zu erzeugen. Finde ich nicht beliebig praktisch, weil die Controls nicht immer an der gleichen Position sind und dann müsste man je nach TargetContainer unterschiedliche Koordinaten definieren. Die zur Designzeit schon zu erzeugen ist da einfacher.

Auch möglich wäre es, via "FindComponent" die Controls zu suchen. Da heißt es (wohl zu recht), dass das nicht empfehlenswert ist, weil langsam und fehleranfällig, wenn sich doch mal ein Controlname ändert.

Ist der Ansatz grundsätzlich verkehrt oder gibt es eine Variante dafür, die ich übersehe?

Danke! Ein frohes neues Jahr!

[Der schöne Günther]

Du kennst aber Frames, oder?

Mache dir doch

1. Eine Basisklasse, welche die abstrakte Methoden getValues(..) und setValues(..) hat, aber sonst noch keine weiteren Controls
2. Je nach Bedarf abgeleitete Klassen, welche dann die gewünschten Controls (Edits, Buttons, ...) beinhalten und die Methoden getValues(..) und setValues(..) implementieren
3. In deinem Code später brauchst du dann nur noch einmal alle Instanzen von deiner Basisklasse durchgehen, Daten abholen, fertig.

[cltom]

Hallo,

stimmt, an Frames hatte ich auch gedacht. Solange sich die Position der Controls nicht ändern soll, wäre das einfach.

Zitat von Der schöne Günther:

1. Eine Basisklasse, welche die abstrakte Methoden getValues(..) und setValues(..) hat, aber sonst noch keine weiteren Controls
2. Je nach Bedarf abgeleitete Klassen, welche dann die gewünschten Controls (Edits, Buttons, ...) beinhalten und die Methoden getValues(..) und setValues(..) implementieren
3. In deinem Code später brauchst du dann nur noch einmal alle Instanzen von deiner Basisklasse durchgehen, Daten abholen, fertig.

sorry, ich fürchte, das verstehe ich noch nicht ganz

Was enthält diese Basisklasse außer den abstrakten Methoden? Das eigentliche Abholen der Daten aus den Edits implementiere ich dann in der abgeleiteten Klasse - wenn ich das mehrmals brauche auf unterschiedlichen ParentControls muss ich das auch mehrmals implementieren?

[Der schöne Günther]

Zitat von cltom:

Was enthält diese Basisklasse außer den abstrakten Methoden?

Nichts. vielleicht ein Label als Überschrift? Die Basisklasse ganz oben ist eher ein "Interface" die sagt "Du kannst hier TDataClass-Dinge reinstecken und rausholen".

Zitat von cltom:

Das eigentliche Abholen der Daten aus den Edits implementiere ich dann in der abgeleiteten Klasse - wenn ich das mehrmals brauche auf unterschiedlichen ParentControls muss ich das auch mehrmals implementieren?

Nein, nur einmal, im Code für deinen abgeleiteten, konkreten Frame. Auf deinem ParentControl kannst du ja dann beliebig viele davon platzieren, aber da schlägst du dich ja nicht mehr mit irgendwelchen Edit-Feldern darin herum, sondern rufst nur noch ein Mal das getValues() auf, um an die eingetragenen Werte in Form deines TDataClass zu kommen.

Ich würde vielleicht einmal mit einem simplen Beispiel loslegen. Das sollte schnell gehen und dann wird einem das bestimmt auch klarer.


PS: Bist du dir sicher, dass du TDataClass wirklich als echtes TObject machen willst? Wenn das nur eine "dumme Datenstruktur" ohne Notwendigkeit für Dinge wie Vererbung und virtuelle Methoden ist ist würde ich das auf jeden Fall als Record machen, dann plagst du dich auch nicht mit Dingen wie der späteren Freigabe (.Free() ) herum.

[MyRealName]

Du kannst auch ein Interface machen und die Methoden GetValue und SetValue darüber implementieren.
Du kannst sogar mehr Controls draufbringen, musst halt beim GetValue und SetValue den Control-Namen mit angeben und das Control suchen, aber ist ja auch kein Hexenwerk.

[Rollo62]

Oder Du tauschst Daten unter verschiedenen Objekten mit Messages aus, wie zum Beispiel mit dem TMessageManager.

[cltom]

Zitat von Der schöne Günther:

Zitat von cltom:

Was enthält diese Basisklasse außer den abstrakten Methoden?

Nichts. vielleicht ein Label als Überschrift? Die Basisklasse ganz oben ist eher ein "Interface" die sagt "Du kannst hier TDataClass-Dinge reinstecken und rausholen".

Zitat von cltom:

Das eigentliche Abholen der Daten aus den Edits implementiere ich dann in der abgeleiteten Klasse - wenn ich das mehrmals brauche auf unterschiedlichen ParentControls muss ich das auch mehrmals implementieren?

Nein, nur einmal, im Code für deinen abgeleiteten, konkreten Frame. Auf deinem ParentControl kannst du ja dann beliebig viele davon platzieren, aber da schlägst du dich ja nicht mehr mit irgendwelchen Edit-Feldern darin herum, sondern rufst nur noch ein Mal das getValues() auf, um an die eingetragenen Werte in Form deines TDataClass zu kommen.

Ich würde vielleicht einmal mit einem simplen Beispiel loslegen. Das sollte schnell gehen und dann wird einem das bestimmt auch klarer.

PS: Bist du dir sicher, dass du TDataClass wirklich als echtes TObject machen willst? Wenn das nur eine "dumme Datenstruktur" ohne Notwendigkeit für Dinge wie Vererbung und virtuelle Methoden ist ist würde ich das auf jeden Fall als Record machen, dann plagst du dich auch nicht mit Dingen wie der späteren Freigabe (.Free() ) herum.

Hallo,

danke für die Rückmeldung!

ok, ich werd's mal versuchen, mal sehen, ob es klarer wird.

ad Datenobjekt: tatsächlich hab ich hier records verwendet für die allermeisten der Datenstrukturen, um die es geht.