Variablen Massenhaft definieren

[KodeZwerg]

Mit Arrays wird es eher übersichtlicher finde ich anstelle dutzende variablen zu nutzen.
Da sollte man ja wissen welches Array für was zuständig ist.
Oder ein Array aus Arrays etc...
Helfen könnte es wenn Du beschreibst was Du eigentlich vorhast, so kommen viele Ideen zur besseren Umsetzung zustande.
(Records, Klassen, Arrays etc...)

[stahli]

... und ein paar Infos zu den eigenen Vorkenntnissen bezüglich Programmierung und Delphi ...
(und zur genutzten Delphi-Version)

[Kegasetu]

Zitat von stahli:

... und ein paar Infos zu den eigenen Vorkenntnissen bezüglich Programmierung und Delphi ...
(und zur genutzten Delphi-Version)

Also ich würde sagen Anfänger. Früher war ich mal besser, aber mittlerweile ist vieles weg. Ich bleibe aber bei diesen Basic Zeug, viel komplizierter wird es nicht.
Ich nutze Delphi 10.3

[KodeZwerg]

Ich würde eine TStringList anstelle lauter Edit-Felder nutzen, dann kannst Du auch easy durchiterieren.
Wenn Dein Array[1..28] lautet auch bei 1 anfangen und nicht bei 0.

Also, Editfelder ein OnChange zuweisen um den Inhalt in die StringList zu pressen, irgendwann später deine for i := 1 to 28 Sache durchführen.

//Edit
Oder generell alles in eine Klasse verfrachten, das erscheint mir am sinnvollsten.

[Kegasetu]

[QUOTE=KodeZwerg;1475798]Ich würde eine TStringList anstelle lauter Edit-Felder nutzen, dann kannst Du auch easy durchiterieren.
Wenn Dein Array[1..28] lautet auch bei 1 anfangen und nicht bei 0.

Also, Editfelder ein OnChange zuweisen um den Inhalt in die StringList zu pressen, irgendwann später deine for i := 1 to 28 Sache durchführen.

Das Problem mit dem StringGrid ist die Übersichtlichkeit für den Anwender. Die Werte müssen räumlich getrennt zu betrachten sein.

[Klaus01]

StringList ist nicht gleich StringGrid

Grüße
Klaus

[Beach]

Zitat von Kegasetu:

[...]
Auch den Arrays bin ich nicht unaufgeschlossen. Ich müsste nur ständig eine Liste parat haben, an der ich ablesen kann, welche Stelle für was steht.
[...]

Ich bin zwar mit Lazarus unterwegs, aber bei Delphi wird es bestimmt vergleichbar sein.
Mir kommt da der Begriff "sprechende variablen" und, wenn ich mich richtig erinnere, "enumerated Types" (?¿) in den Kopf.

Ein Beispiel

Code:

  DataLoaded_keys: (cfg, xpc, ypc, zpc);
  DataLoaded: array[cfg..zpc] of boolean;

Das Array kann ich dann "sprechend" mit DataLoaded[xpc], als Beispiel, verwenden und gibt mir dann den boolschen Hinweis ob die Daten geladen wurden oder nicht.
Es "liest" sich recht eindeutig was man gerade macht. Geht auch mit mehrdimensionalen Arrays.

Die Spezialisten hier können das bestimmt korrigieren und besser erklären.

[KodeZwerg]

Wenn ich mir das Bild anschaue, würde ich mir ein Array mit Typ Record erschaffen die dann ComboBox.Index <Bauteil> gleich sind.
Das Record mit dementsprechend viele Strings bereitstellen (Konvertierung StrToInt/IntToStr würde ich da raushalten)
Bei <Abschnitt> habe ich keine Ahnung was da passiert, also lasse ich das mal außen vor.

[stahli]

Also grundsätzlich gibt es viele Möglichkeiten ... je nachdem, welche Konzepte man einsetzen möchte.

Ich würde mal denken, Klassen und Generics sind hier auszuschließen.

Die Daten also entweder in einfache Variablen, wie Du es angedeutet hast, oder in Arrays. Du musst einfach sehen, was für Dich praktikabler ist.

Wichtig wäre, Formular und Logik zu trennen.
Man könnte als Schnittstelle zwei Funktionen definieren:

DatenInFormularSchreiben und DatenAusFormularHolen.
Dort realisierst Du das, was Du im Eingangspost gemacht hast.
Nur die zwei Funktionen sollten die Controls und die Variablen benutzen.
Dann brauchst Du noch eine Funktion BerechneDaten, die z.B. von einem Button angestoßen wird.

Dort sollten alle Berechnungen ablaufen, ohne noch einmal auf ein Edit oder anderes Control zuzugreifen.

In DatenAusFormularHolen kannst Du zwar so etwas wie FindControl('Edit1') benutzen, aber es wird einfacher sein, wenn Du es wie im Eingangspost machst und direkt Edit1.Text benutzt.
Allerdings würde ich den Controls immer sprechende Namen zuordnen, also z.B. zg111 := StrToInt(Edit_zg111.Text);
Das vereinfacht schon mal einiges und vor allem die Wartung und Fehlersuche.

Soweit vielleicht erst mal als Richtungsempfehlung...

[Kegasetu]

Zitat von stahli:

Also grundsätzlich gibt es viele Möglichkeiten ... je nachdem, welche Konzepte man einsetzen möchte.

Ich würde mal denken, Klassen und Generics sind hier auszuschließen.

Die Daten also entweder in einfache Variablen, wie Du es angedeutet hast, oder in Arrays. Du musst einfach sehen, was für Dich praktikabler ist.

Wichtig wäre, Formular und Logik zu trennen.
Man könnte als Schnittstelle zwei Funktionen definieren:

DatenInFormularSchreiben und DatenAusFormularHolen.
Dort realisierst Du das, was Du im Eingangspost gemacht hast.
Nur die zwei Funktionen sollten die Controls und die Variablen benutzen.
Dann brauchst Du noch eine Funktion BerechneDaten, die z.B. von einem Button angestoßen wird.

Dort sollten alle Berechnungen ablaufen, ohne noch einmal auf ein Edit oder anderes Control zuzugreifen.

In DatenAusFormularHolen kannst Du zwar so etwas wie FindControl('Edit1') benutzen, aber es wird einfacher sein, wenn Du es wie im Eingangspost machst und direkt Edit1.Text benutzt.
Allerdings würde ich den Controls immer sprechende Namen zuordnen, also z.B. zg111 := StrToInt(Edit_zg111.Text);
Das vereinfacht schon mal einiges und vor allem die Wartung und Fehlersuche.

Soweit vielleicht erst mal als Richtungsempfehlung...

Klassen? Um Himmels Willen, bloß nicht

So sieht das Programm aus, vielleicht wird es dann etwas klarer, was ich machen will (Bild im Anhang).

Es sollen erstmal ein paar Informationen eingegeben werden und dann gespeichert. Durch den Button "Auswählen" sollen die Informationen dann wieder in den Edit-Feldern erscheinen.

Ich frage mal ganz frech. Gibt es dafür eventuell einen vorgefertigten Code? Eigentlich ist es ja relativ simpel.