alle Edits durchlaufen und Edit_x_.Text einer Grid-Column zuweisen

[juergen]

Hallo zusammen,

auf einem Panel habe ich ca. 30 Edits, wobei jedes Edit eine Überschrift für eine Spalte in einem Grid bedeutet.
Das Grid kann x Anzahl von Spalten haben.
Die Anzahl der vorhandenen Grid-Spalten zu ermitteln ist kein Problem.
Die Überschrift pro Spalte zu setzen ist auch kein Problem.

Aber wie könnte ich den Text von Edit 1 in Spalte 1 übernehmen, ... den Text von Edit 15 in Spalte 15 übernehmen usw.
Ich muss dazu irgendwie eine Schleife durchlaufen ala:

Delphi-Quellcode:

for i := Pred(cxGrid1DBTableView1.ColumnCount) downto 0 do begin
  cxGrid1DBTableView1.Columns[i].Caption := Edt_(i).Text // Pseudocode???
end;

Ich würde hier ungern mit zig If-Bedingungen arbeiten wollen, da gibt es bestimmt eine bessere Lösung.

Für Hinweise bedanke ich mich schon mal vorab!

[mkinzler]

Z.B. mit Panel.FindComponent()

[Mavarik]

Oder herkömmlich...

Delphi-Quellcode:

Edits[0] := Edit1;
Edits[1] := Edit2;

usw.

Klingt mir wieder mal nach "Datenhaltung" in Kontrolls...

Baue Dir doch zur Datenhaltung lieber einen Klasse oder ein Record..

Und das wird dann eben dargestellt oder angezeigt...

[juergen]

Hallo,

beim schreiben hier wurde mir klar dass ich mit einer 2. Schleife die Componenten durchlaufen muss...
Mein jetziger Code:

Delphi-Quellcode:

  for i := 0 to Pred(cxGrid1DBTableView1.ColumnCount) do begin
    for j := 0 to ComponentCount - 1 do begin
      if (Components[j] is TEdit) and (TEdit(Components[j]).Tag = i) and (TEdit(Components[j]).Tag > 0) then  cxGrid1DBTableView1.Columns[i].Caption :=  TEdit(Components[j]).Text;
    end;
  end;

Das Problem dabei ist, dass die erste Spalten-Überschrift leer bleibt und ich gerade nicht weiß warum.:?:

[juergen]

So, ich hab's. Da die Tag-Eigenschaft mit 1 beginnt und nicht mit Null muss ich beim Vergleich dann auch eine "1" dazuzählen...:oops:

Delphi-Quellcode:

  // Spaltenmueberschriften dynamisch zur Laufzeit setzen...
  for i := 0 to Pred(cxGrid1DBTableView1.ColumnCount) do begin
    for j := 0 to ComponentCount - 1 do begin
      if (Components[j] is TEdit) and (TEdit(Components[j]).Tag = i + 1) and (TEdit(Components[j]).Tag > 0) then
          cxGrid1DBTableView1.Columns[i].Caption := TEdit(Components[j]).Text;
    end;
  end;
end;

Vielen Dank und allen noch einen schönen Sonntag! :dp:

[Sir Rufo]

Bei 30 Edits und 30 Spalten werden hier 900 Iteration durchgeführt.

Klingt ein wenig viel ... :stupid:

Es reicht völlig

Delphi-Quellcode:

for j := 0 to ComponentCount - 1 do begin
  if (Components[j] is TEdit) and (TEdit(Components[j]).Tag > 0) then
    cxGrid1DBTableView1.Columns[TEdit(Components[j]).Tag-1].Caption := TEdit(Components[j]).Text;

Dann waren es nur noch 30 ;)

[juergen]

@Sir Rufo,

du hast so Recht. Danke für deine Aufmerksamkeit und das Aufzeigen wie es richtig gemacht wird!:thumb:

Einen schönen Sonntag!

[haentschman]

Hallöle...8-)

Zitat:

...wie es richtig gemacht wird.

...ganz richtig wäre, wie schon erwähnt, eine Trennung von GUI und Daten.

Zitat:

Klingt mir wieder mal nach "Datenhaltung" in Kontrolls...
Baue Dir doch zur Datenhaltung lieber einen Klasse oder ein Record..

...ist die Lösung. :thumb:

[juergen]

Hallo haentschman,

das Ganze ist ein "Konfigurations-Tool" für das Quantumgrid.
Man wählt die DB aus, z.B. MSSQL, gibt die Überschriften pro Spalte vor, wählt den Datentyp pro Spalte aus, definiert pro Spalte ob Summenbildung erfolgen soll und gibt dann
ein SQL-Statement vor welches das Quantumgrid "befeuert". Diese Konfiguration lässt sich jeweils speichern.

Ich kann nun gar nicht abschätzen ob ich dafür den richtigen Weg gehe oder die GUI für Datenhaltung missbrauche. Für ein Konfigurations-Tool würde *ich* sagen das wäre so OK, oder?

[haentschman]

:P

Zitat:

Man wählt die DB aus, z.B. MSSQL, gibt die Überschriften pro Spalte vor, wählt den Datentyp pro Spalte aus, definiert pro Spalte ob Summenbildung erfolgen soll und gibt dann
ein SQL-Statement vor welches das Quantumgrid "befeuert". Diese Konfiguration lässt sich jeweils speichern.

Das ist ein Klassiker für eine Datenklasse die erstmal doof nur die Daten (Konfiguration) hält und ggf. über das SQL Statement die Daten holt, das Speichern und Laden übernimmt.
Letztendlich brauchst du nur die Klasse auslesen und die enthaltenen Daten den entsprechenden Controls übergeben. Umgekehrt werden Änderungen in den Controls in der Klasse abgelegt. Somit bist du unabhänging ob die Anzahl der Spalten in einem Edit mit rosa Rahmen, einem Spinedit mit Schleifchen etc. dargestellt wird. :thumb: Deine Logik arbeitet mit der Klasse. Denn sie hat die Controls nicht zu kennen. Ein Iterieren über die Controls um Daten abzufragen kommt nur in Frage wenn die Arche Noah ausgelaufen ist... :lol:

PS: Auch gerade bei eigenen Tools ist die Trennung wichtig, da einem immer wieder Erweiterungen einfallen die sonst an die Grenzen stoßen würden. :wink: