Datensatzmaske automatisiert erzeugen?

[I.A]

Hallo,

vor einigen Tagen gab es die Frage mit dem Titel "Beliebig viele Editfelder erzeugen". Nun beschäftige ich mich gerade mit dem Tutorial "Datenbanken" aus dem "Delphi Treff".

Bei den Grundsätzen zur Datenbankentwicklung gibt es die Regel, das das Datenbankprogramm unabhängig von der konkreten Datenstruktur sein muss. Deshalb komme ich wieder auf die Frage der beliebig vielen Edifelder zurück.

Gibt es einen möglichst eleganten Weg, im Dataset das aktuelle Feld zu finden, das einem DBEdit dann zuzuweisen wäre. Zunächst mal in der Reihenfolge der Felder, wie sie physich in der Datenbank stehen?

Im Dataset gibt es die Eigenschaft Fields['Feldname']. Ich brauche aber eher eine Eigenschaft Fields[Index]: Typ des Datenfeldes, wie es der DBEdit-Komponente zu übergeben ist. Hab ich in der Delphi Hilfe die passende Eigenschaft übersehen? Einer meiner Computerfreunde hat das Buch "Delphi für Kids", die Ausgabe mit Delphi 3. Dort war ein Datenbankexperte dabei, der solche Eingabemasken automatisch erzeugen konnte. Die Programmierer von Delphi müssen also auch einen effizienten Weg gefunden haben, diese Maske von der Datenstruktur abhängig, automatisch zu erzeugen. Wie würdet Ihr das machen. Bisher habe ich das so gelöst:

Delphi-Quellcode:

procedure TForm1.CreateMask;
var
  edx: Integer;
  idx: Integer;
  topy: Integer;
  leftx: Integer;
  edit: TEdit;
begin
  topy := 3; leftx := 10;
  if ClientDataSet.Active then
  for idx := 0 to ClientDataSet.FieldCount - 1 do begin
    edx := FControls.Add(TEdit.Create(self));
    FControl := FControls.Items[edx];
    if FControl is TEdit then
    begin
      edit := TEdit(FControl);
      edit.Top := topy;
      edit.Left := leftx;
      edit.Parent := MaskBox;
      inc(topy, edit.Height + 3);
    end;
  end;
end;

Mit Stringliste statt TObjectList könnte das so aussehen:

Delphi-Quellcode:

procedure Tdbmain.CreateMask;
var
  FieldNum: Integer;
  EditIdx: Integer;
  Field: TStrings;
  FieldName: String;
  TopPos,LeftPos: Integer;
begin
  TopPOs := 15; LeftPos := 40;
  Field := TStrings.Create;  //hier sind die Felnamen gespeichert, für Labels verwendbar
  dbf.Fields.GetFieldNames(Field);
  for Fieldnum := 0 to dbf.FieldCount-1 do
  begin
    Editidx := FEdits.AddObject('',TLabeledEdit.Create(self));
    FCtrl   := FEdits.Objects[EditIdx];
    if FCtrl is TLabeledEdit then
    begin
      FEdit        := TLabeledEdit(FCtrl);
      FEdit.Left   := 40;
      FEdit.Top    := TopPos;
    //FEdit.Text   := dbf.FieldByName(Field[FieldNum]).AsString;
      FEdit.Text   := dbf.Fields.Fields[Fieldnum].AsString;
    //FEdit.DataSource := DataSource;
      FEdit.Parent := self;
    end;
    Inc(TopPos, FEdit.Height + 5);
  end;
  Field.Free;
end;

Nun will ich statt des TEdit ein TDBEdit verwenden, welchem ich das richtige Datenfeld zuordnen will. Welche Lösung(en) gibt es da.

[mschaefer]

Ja das läuft analog zu Deinem Beispiel nur mußt Du jedem Feld die DataSource zuweisen und das Datenbankfeld.
Während der Zuweisung solltest Du die DataSource aber Diasable´n.

Man könnte das sogar mit verschiedenen Feldtypen DBEdit, DBMemo, machen. Eine Möglichkeit ist dann die Auswahl des Feldetyps anhand des Feldnamens oder einer Namenserweiterung: Name, Name_Memo, Name_Grid, Name_Pict usw.

Und im dann könnte man noch die Labels davor plazieren, aber erstmal klein Anfangen. Ich denke, gerade wenn ein System dazu neigt erweitert zu werden, dann ist das eine richtig spannende Sache!

Viele Grüße // Martin

[I.A]

Hallo Martin

Zitat von mschaefer:

Ja das läuft analog zu Deinem Beispiel nur mußt Du jedem Feld die DataSource zuweisen und das Datenbankfeld.
Während der Zuweisung solltest Du die DataSource aber Diasable´n.

Man könnte das sogar mit verschiedenen Feldtypen DBEdit, DBMemo, machen. Eine Möglichkeit ist dann die Auswahl des Feldetyps anhand des Feldnamens oder einer Namenserweiterung: Name, Name_Memo, Name_Grid, Name_Pict usw.

Und im dann könnte man noch die Labels davor plazieren, aber erstmal klein Anfangen. Ich denke, gerade wenn ein System dazu neigt erweitert zu werden, dann ist das eine richtig spannende Sache!

Ja das kann spannend werden.

Das mit den Feldnamen abhängig vom zu wähleneden Steuerelement ist ne klasse Anregung. Ich wollte es vom Datentyp
abhängig machen.

-Datentyp String <DBEdit>
-Datentyp Zahl (Float oder Integer) <DBEdit>
-Datentyp Memo <DBMemo>

Aber da kommt das Problem, wann muss eine DBComboBox ausgewählt werden? Bei einem logischen Feld
Typ 'L' im guten alten Dbase oder Typ Boolean könnte DBComboBox oder DBCheckbox in Frage kommen.
Der Eine Kunde könnte die ComboBox bevorzugen, der Andere die ChaecBox.
Bei einem Stringfeld kann ein einfaches Editfeld die richtige Wahl sein, ebenso die DBCombobox.
Das hängt von der Art der Daten ab. Automatisiert könnte man immer DBEdit-Komponenten erzeugen.

Besser wäre eine Komponente, die je nach konkreter Datenmenge die Eingabekomponente einstellbar
macht. Aber das Datenbankprogramm soll unabhängig von den Daten sein. Hier widersprechen sich
schon mal 2 Anforderungen und ein Kompromiss muss gesucht werden. Es bleibt eine spannende Aufgabe.

Die Feldnamen mit passender Erweiterung, (Name_Pict, Name_Cbx...) werde ich als Anregung mitnehmen.
Danke. Den Tabellenspalten wie den Labels (DBText) können ja Feldnamen ohne die Erweiterung zugewiesen
werden. Ich bleibe dran.

Es grüßt Dich Hartmut

[mquadrat]

Zitat:

Im Dataset gibt es die Eigenschaft Fields['Feldname']. Ich brauche aber eher eine Eigenschaft Fields[Index]: Typ des Datenfeldes, wie es der DBEdit-Komponente zu übergeben ist. Hab ich in der Delphi Hilfe die passende Eigenschaft übersehen

Fields[index]: TField müsste es doch geben?!


Zum Thema unterschiedliche Komponente bei unterschiedlichen Anwendungen bei gleichem Datentyp: Schreib dir doch ne Klasse, die eine Methode enthält, der du das Feld übergibst und die dann das passende Control zurückgibt. Intern kann die dann ja den Aufruf auf eine Methode je Datentyp verteilen. Brauchst du in einer Anwendung dann ein anderes Verhalten vererbst du deine Standardklasse und passt das dort entsprechend an.

Woran du aber denken solltest: Felder in der Reihenfolge der Datenbank machen wenig Sinn. Man gruppiert ja meist nach logischen Gesichtspunkten und nicht chronologisch nach Einfügen der Felder. Du solltest dor also schon mal überlegen wie du die Reihenfolge deiner Felder festlegen willst. Außer natürlich das ist nur für's Prototyping gedacht.

[shmia]

Die Komponente oder das Control, das du suchst heisst "Vertical DBGrid".
Hier ist ein früher Versuch von mir, alle Labels und DBEdits dynamisch zur Laufzeit zu erzeugen:
http://www.delphipraxis.net/internal...ct.php?t=22654

[I.A]

Hallo!

Ich habe das Ganze jetzt unabhängig von Dir @Martin und Dir @shmia so hier gelöst:

Delphi-Quellcode:

  TDBInputMask = class(TCustomInputMask)
  //diese Klasse für Datenbankmasken verwenden
  //Feldanzahl, damit Anzahl Edits wird durch die Datenbank bestimmt
  private
    FDataSource: TDataSource;
    FEdits: TStrings;    //Feldnamen nach Anzeigereihenfolge
    function GetInputs(Index: Integer): TObject;
    function GetLabels(Index: Integer): TDBText;
    function GetMasks(Index: Integer): String;
    function GetDataSource: TDataSource;

    procedure SetCount(ACount: Integer);
    procedure SetInputs(Index: Integer; AInput: TObject);
    procedure SetLabels(Index: Integer; ALabel: TDBText);
    procedure SetMasks(Index: Integer; AMask: String);

    procedure SetDataSource(ADataSource: TDataSource);
  public
    constructor Create(AOwner: TComponent);
    procedure CreateLabel(ACaption: TCaption); override;
    procedure CreateLabelCaptions(ACaptions: TStrings);
    procedure CreateEdit(AEditMask: String); override;
    procedure CreateCheckBox(ACaption: String); override;
    procedure CreateComboBox; override;
    procedure CreateMask; override;
    procedure CreateMemo; override;
    procedure CreateRadioGroup(ACaptions: TStrings); override;
    procedure CreateRichEdit; override;
    destructor Destroy; override;

    property Count: Integer read FCount write SetCount;
    property DataSource: TDataSource read GetDataSource write SetDataSource;
    property Inputs[Index: Integer]: TObject read GetInputs write SetInputs;
    property Masks[Index: Integer]: String read GetMasks write SetMasks; default;
  end;

Die Implementation ist noch nicht ganz ausgereift, daher bring ich hier nur meinen Ansatz. Die Klasse TCustomInputMask ist nix weiter als ein abstrakter Vorfahre, der alle public-Methoden abstrakt definiert. Diese müssen von konkreten Nachfahren auf jeden Fall überschrieben werden.

@mquadrat: Fields[Index] gibt es leider nicht. Es gibt nur Dataset.GetFieldnames(AFieldnames), wobei AFieldnames eine Stringliste sein muss. Ich hoffe mal, das hier die Feldnamen in der jeweils richtigen Reihenfolge übergeben werden.

Die Maske erzeuge ich im Prinzip nach der Vorgehensweise wie im Thread "" erklärt wurde, nur, das es sich hier um die Datenbank-Äquivalente habdelt.

Die Methoden CreateEdit(), CreateComboBox()... erzeugen die Controls zunächst von Hand. Ich habe aber die Möglichkeit vorgesehen standardmäßig DBEDits zu erzeugen. Das passiert in der Methode SetDataSource. Dort will ich später datentypabhängig spezialisierte Controls erzeugen, wobei @shmia einen guten Anstz liefert. @mschaefer hat mir per PN eine passende Klasse gesendet, deren Quelltext ich erst mal bissl studieren muss. Aber das Prinzip ist schon mal das gleiche, wie ich es gemacht habe, nur werden die Controls anders erzeugt.

Ich habe auch den Tipp mit geeigneten Feldnamen berücksichtigt. Heutige Datenbanken können ja recht lange Feldnamen haben. Da könnte ich dann folgendes machen:

Feldname Labelname (wird von DBText bzw als Spaltenüberschrift angezeigt)

Artikel__edt Artikel <Control ist ein Editfeld>
Vorrätig__chbox Vorrätig <Control ist eine Checkbox>

Das Kennzeichen, das mein Felname eine Erweiterung hat, die auf das zu verwendende Control hinweist, ist der doppelte Unterstrich. Ein einfacher Unterstrich ist dagegen im Feldnamen nicht nur erlaubt, sondern wird zur Benennung auch oft genug verwendet. ABer der doppelte Unterstrich dürfte im Feldnamen schon seltener sein. Ist zumindest auf der Arbeitsstelle meines Vaters so.


Ebenso könnte der Datentyp berücksichtigt werden, der in der Datenbank gespeichert ist. Dann könnte, wie nach dem Vorschlag von @shmia datentypabhängig ein passendes Eingabefeld ausgewählt werden.

Meine Eingabemaske kann bisher nur entweder die Standardmäßigen DBEdits erzeugen, die später mittels Eigenschaft Inputs durch spezialisiertere Controls ersetzt werden können. Oder ich weiß vrher, welche Controls am geeignetsten sind und erzeuge sie mit CreateXXXXXX(). Wenn ich weiß, welche Controls da zu wählen sind, kenne ich ja auch die Anzahl der Datenbankfelder.

Die Aufgabe, die ich mir hier gestellt habe bleibt interessant. Ich melde mich wieder, wenn ich neue Erkenntnisse gewonnen oder meine Eingabemaske weiter entwickelt habe.