Werte von stringgrid zellen zusammenrechnen

[rhodan]

hi..

mit folgendem code addiere ich die werte von stringgrid zellen zusammen und weise sie einem editfeld zu:

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
Z1, Z2,z3: extended;
begin
  z1 := strtofloatdef(Grid.Cells[1,1], 1);
  z2 := StrTofloatdef(Grid.Cells[2,1], 1);
  z3 := StrTofloatdef(Grid.Cells[3,1], 1);
  edit1.text:= floattostr((z1+z2+z3));
end;

mein problem ist das die anzahl der Columns nicht feststehend ist, der user kann neue hinzufügen oder löschen...hat jemand eine idee wie ich das umsetzen kann? im prinzip muss die anzahl der bestehenen columns ausgelesen werden (in diesem falle 3) und die werte der drei addiert werden...wenns 5 sind eben der 5...etc...
könnt ihr mir nen tip geben?

ich schätze mal ich muss den grid.colcount einem integer zuweisen, aber bei dem rest steh ich auf dem schlauch.

lg

lg robin

[zeras]

Zitat:

Zitat von rhodan (Beitrag 1257754)

hi..

ich schätze mal ich muss den grid.colcount einem integer zuweisen, aber bei dem rest steh ich auf dem schlauch.

Du musst grid.rowcount und grid.colcount auslesen (nicht zuweisen), damit die Grenzen bestimmen und dann alles zusammenrechnen, d.h. in jeder Zeile alls zusammenrechnen und das für alle Zeilen tun.
Vorher aber noch aufpassen, dass du eventuelle Kopftexte nicht mit zum Rechnen nutzt. Außerdem solltest du vorher prüfen, ob es überhaupt Zahlen sind.

[mkinzler]

Die vorhandene Anzahl von Spalten kannst Du ermitteln, indem du Grid.ColCount abfragst.

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
  z: Extended;
  i: integer;
begin
  z := 0;
  for i := 0 to Grid.ColCount-1 do
  begin 
    z :=  z + strtofloatdef(Grid.Cells[i,1], 1);
  end;
  edit1.text:= floattostr(z);
end;

[rhodan]

ich danke dir!
ich hab hier das problem das leere zellen als 1 komischerweise gezählt werden...ich löse das jetzt so das ich in der column jede leere zelle mit '0' fülle schätze ich.
es geht um die zeile "stunden pro woche", hier kriege ich eine 43 als ergebnis.

liebe grüße

[mkinzler]

Einfach 0 als Standardwert statt 1.

[rhodan]

danke dir !

[Popov]

Es ist keine gute Idee mit StrToFloatDif zu arbeiten. Damit vermeidest du zwar eine Fehlermeldung, aber die Fehlermeldung hat einen Sinn. Sie warnt davor wenn ein Fehler auftritt. Schreibt einer in Spalte Robin den Wert "321.45", bekommst du den Fehler gar nicht mit. Der Wert wird in StrToFloatDif genullt und taucht in der Statistik nicht auf. Wenn du nicht die Standardfehlermeldung haben willst, kannst du eine eigene schreiben. Hier zwei Beispiele:

Delphi-Quellcode:

function StrToFloatSG(const S: String; ACol, ARow: Integer): Extended; overload;
begin
  if StrToFloatDef(S, 0) <> StrToFloatDef(S, 1) then
    raise Exception.CreateFmt('Ungültiger Wert in Zelle [%d.%d]', [ACol, ARow]);

  Result := StrToFloat(S);
end;

function StrToFloatSG(const S, SCol, SRow: String): Extended; overload;
begin
  if StrToFloatDef(S, 0) <> StrToFloatDef(S, 1) then
    raise Exception.CreateFmt('Ungültiger Wert in Spalte "%s" und Zelle "%s"', [SCol, SRow]);

  Result := StrToFloat(S);
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  z: Extended;
  i: integer;
begin
  z := 0;
  for i := 0 to Grid.ColCount-1 do
  begin
    //z := z + strtofloatdef(Grid.Cells[i,1], 1);
    //z := z + StrToFloatSG(Grid.Cells[i,1], 1, i);
    z := z + StrToFloatSG(Grid.Cells[i,1], Grid.Cells[1, 0], Grid.Cells[0, 1]);
  end;
  edit1.text:= floattostr(z);
end;

Die erste gibt die Zeile und Spalte als Wert zurück, bei der Zweiten kannst du die Überschriften angeben. Und lass dich von der bösen Fehlermeldung in der Entwicklungsumgebung nicht abschrecken. Stäter, aus der Exe heraus, sieht die harmloser aus.

[DeddyH]

Da wäre TryStrToFloat aber erheblich zielführender und vor allem verständlicher.

[mkinzler]

Ich würde auch eher versuchen falsche Eingaben zu verhindern

[Sir Rufo]

Generell ist es immer besser die Controls nicht als Werte-Speicher zu gebrauchen.

Die Intention ist Daten anzuzeigen und (wenn Eingaben möglich sind) Eingaben entgegen zu nehmen.
Diese Eingaben sollten dann direkt nach der Eingabe auf Plausibilität und Kontext geprüft werden und in einer Datenstruktur gespeichert werden. Im Control werden dann diese (geprüften) Werte wieder dargestellt.

Aggregate (z.B. Summenbildung) erfolgen dann über die Datenstruktur.

[DeddyH]

Stimmt, das hat außerdem den Riesenvorteil, dass man an der Oberfläche herumändern kann, wie man will (z.B. das StringGrid gegen eine Listview austauschen), ohne dass davon die Logikschicht beeinflusst wird.

[zeras]

Zitat:

Zitat von Sir Rufo (Beitrag 1257788)

Generell ist es immer besser die Controls nicht als Werte-Speicher zu gebrauchen.

Die Intention ist Daten anzuzeigen und (wenn Eingaben möglich sind) Eingaben entgegen zu nehmen.
Diese Eingaben sollten dann direkt nach der Eingabe auf Plausibilität und Kontext geprüft werden und in einer Datenstruktur gespeichert werden. Im Control werden dann diese (geprüften) Werte wieder dargestellt.

Aggregate (z.B. Summenbildung) erfolgen dann über die Datenstruktur.

Und das macht ihr auch, wenn ein Stringgrid mit über 100 Werten gefüllt und editierbar ist?
Nur mal so als Frage.

[DeddyH]

Was spricht denn dagegen?

[zeras]

Zitat:

Zitat von DeddyH (Beitrag 1257815)

Was spricht denn dagegen?

Nach meinem Eindruck macht das erst mal mehr Arbeit, könnte sich dann aber auszahlen, wenn etwas zu portieren o.ä. zu machen ist.
Habe ich bei meinen Projekten nicht umgesetzt, könnte aber mal bei neueren Projekten darüber nachdenken.

"Wenn ihr das alle so macht, wird es ja nicht verkehrt sein."

[himitsu]

- man kann Code problemlos wiederverwenden
- man kann die GUI problemlos umbauen
- oder die GUI ganz abtrennen

Vorallem wenn man mal eine andere/bessere Komponente haben möchte oder wenn es um Bugfixes geht.

[Popov]

Das ist ja das Problem dran, man sollte stets Profi- und Hobbyprogrammierung beachten. Ein Profi kann sein Codes vermutlich irgendwann erneut nutzen, eine Hobbyprogrammierer eher nicht. Somit stellt sich die Frage wie perfekt sollte man seine Programme machen?

[Sir Rufo]

Hmmm, eigentlich wird die Programmierung selber durch die Trennung einfacher.

Sind die Werte in einem Control gespeichert (zu 99% immer als string), muss ich mich bei einer Berechnung mit dem Control, der Umwandlung und der Berechnung auseinandersetzen (jonglieren mit 3 Bällen).

Sind die Werte in einer simplen Liste gespeichert (im richtigen Format), dann muss ich mich bei der Berechnung nur mit der Liste und der Berechnung auseinandersetzen.

Die einzige Hürde ist das Zusammenspiel zwischen dem Control und der Daten-Struktur.
Hier sehe ich aber als Hauptproblem nicht den Anfänger, denn der lernt meistens aus Büchern oder dem Internet. Und wenn der dann dort ausschließlich Beispiele findet, wo im OnClick-Handler eines Buttons der gesamte Weltbeherrschungscode ausgeführt wird oder eben der "Missbrauch" von Controls als Datenspeicher vorgemacht wird, dann hat er als Anfänger keine andere Chance als zu glauben, dass man das so macht.

Weitere Fragen in einem Forum bestärken ihn auch noch in diesem Glauben.

Der RAD-Ansatz von Delphi (wurde zuletzt mit einem Click-Adventure verglichen) erledigt dann noch den Rest.

Ein Beispiel: http://www.delphi-treff.de/tutorials...ner/quellcode/

[DeddyH]

Genau. Wer hat das als Anfänger nicht so gemacht und sich später geärgert, dass eine simple Darstellungsänderung einen Rattenschwanz von Codeänderungen nach sich zog? Ich will mich selbst davon nicht ausnehmen, aber man lernt ja ständig dazu. Und wenn man unliebsame Erfahrungen durch Befolgen guter Ratschläge vermeiden kann, umso besser.

[Popov]

Ok, das soll jetzt nicht nach dem das-letzte-Wort-haben-wollen, aber seinen wir mal ehrlich ...

Zitat:

Und wenn man unliebsame Erfahrungen durch Befolgen guter Ratschläge vermeiden kann, umso besser.

...wenn die Kinder immer die guten Ratschläge ihrer Eltern befolgen würden, hätten wir kein Überbevölkerungsproblem auf der Erde ;)

Manchmal müssen die Leute ihre eigenen Erfahrungen sammeln. Und wenn sie irgendwann gemerkt haben, dass eine Sache nicht optimal läuft, werden sie schon fragen wie es besser geht.

[DeddyH]

Findest Du diese Art der Argumentation nicht selbst etwas bescheuert? Oder soll jeder Fahrlehrer seine Schüler erst einmal vor den Baum fahren lassen, damit sie diese Erfahrung einmal gemacht haben und somit das Fahren gegen Bäume künftig zu vermeiden versuchen?

[Sir Rufo]

@Popov

Natürlich sollen alle ihre eigenen Erfahrungen sammeln, hier ist der Fall aber anders.
Es wird "falsch" vorgemacht und dann genauso nachgemacht.

Hier werden keine eigenen Erfahrungen gemacht, sondern hier wird abgeschaut (Lernen durch Nachahmung).
Die Erfahrung: Ich bin an einem Punkt, da geht es nicht so richtig weiter, bzw. die Komplexität der Programmierung steigt exponential zur Komplexität der Aufgabe.

Hier geht es doch um das Grundwissen (vergleichbar mit "Laufen lernen" oder "Sprechen lernen"). Bekomme ich das als Anfänger immer wieder falsch vorgemacht, dann übernehme ich das so (auch wenn es falsch ist).

[Popov]

Zitat:

Zitat von DeddyH (Beitrag 1257861)

Findest Du diese Art der Argumentation nicht selbst etwas bescheuert? Oder soll jeder Fahrlehrer seine Schüler erst einmal vor den Baum fahren lassen, damit sie diese Erfahrung einmal gemacht haben und somit das Fahren gegen Bäume künftig zu vermeiden versuchen?

Es ist nichts frustrierender als etwas richtig zu machen ohne zu wissen warum man es so machen muss. Dann gibt es irgendwann diese Unterhaltung: wieso machst du das so? Weil es richtig ist. Ist es wirklich richtig? Ich weiß es nicht, man hat es so mir gesagt.

Ich gebe dir natürlich insoweit Recht, dass wir nicht alles Try and Error lernen können. Das ist die langsamste Methode zu lernen, auf der anderen Seite aber nicht zu wissen warum etwas besser oder richtige ist, erzeugt nur "Fachidioten". Leute die die Theorie perfekt beherrschen, sie aber nicht auf die Praxis anwenden können. Gelegentlich gehört der Acha-Effekt zum Leben dazu.

Was den Führerschein angeht, so hast du natürlich Recht. Aber ich denke mir der Acha-Effekt kommt später in der Praxis.

[Popov]

Zitat:

Zitat von Sir Rufo (Beitrag 1257862)

..Hier werden keine eigenen Erfahrungen gemacht, sondern hier wird abgeschaut (Lernen durch Nachahmung).
...

Hier geht es doch um das Grundwissen (vergleichbar mit "Laufen lernen" oder "Sprechen lernen"). Bekomme ich das als Anfänger immer wieder falsch vorgemacht, dann übernehme ich das so (auch wenn es falsch ist).

In dem Punkt stimme ich dir 100% zu, aber nur unter einer Voraussetzung: entweder man macht es so oder so, aber man mischt nicht beides zusammen. Entweder man überlässt den Fragenden sich selbst und antwortet nur auf seine Fragen, dann lernt er selbst und Try and Error. Oder er man will ein Ausbilder sein und jemandem zeigen wie man es macht, bzw. es richtig macht. Dann muss man ihm auch genau vormachen wie es geht. So funktioniert es auch in der Praxis - der Lehrer oder Dozent erklärt es zuerst und gibt Aufgaben, der Ausbilder macht es vor und prüft die Ergebnisse, usw. Aber einfach zu sagen - das ist falsch, anders ist richtig, aber dieses Anders mußt du dir schon selbst beibringen, also ich weiß nicht ob man das als Lehren bezeichnen kann.

[Sir Rufo]

@Popov

Darum haben solche Tutorials es ja eigentlich in der Hand die Quick-And-Dirty Lösung zu einer saubereren Lösung weiter zu entwickeln immer mit dem Hinweis darauf, warum man das jetzt so macht.

Aber der Anfänger wird einfach mit dem QAD abgespeist und gut ist.
Wann soll denn der Aha-Effekt kommen?

• Durch andere Tutorials mit ähnlichem Anspruch (QAD reicht)?
• Durch Rückfragen in einem Forum (QAD? Mach weiter so)?

Das ist der Grund warum ich manchmal den Fragestellern mit so komischen Sachen auf den Wecker falle wie:

• Hast du das schon mal mit Papier und Bleistift ausprobiert?
• Was willst du jetzt schon mit einem StringGrid?

In diesem Zusammenhang passt auch gut

Zitat:

Zitat von heise.de

Der Wegbereiter der strukturierten Programmierung, Edsger Dijkstra, äußerte 1975, dass es nahezu unmöglich sei, Studenten ein gutes Programmieren beizubringen, die vorher mit BASIC in Berührung gekommen seien.

Quelle: http://www.heise.de/developer/meldun...m-2178897.html

[mkinzler]

Aber nur mit Trial and Error lernt man auch recht wenig.

[Perlsau]

Zitat:

Zitat von Sir Rufo (Beitrag 1257873)

Zitat:

Zitat von heise.de

Der Wegbereiter der strukturierten Programmierung, Edsger Dijkstra, äußerte 1975, dass es nahezu unmöglich sei, Studenten ein gutes Programmieren beizubringen, die vorher mit BASIC in Berührung gekommen seien.

Das kann ich aus eigener leidvoller Erfahrung bestätigen: Ich werde nie vergessen, wie ich mich als Basic-Grubbler 1993/1994 dabei anstellte, Turbo Pacal zu erlernen und wie schwer mir das anfangs fiel. Kein Goto, kein Peek&Poke, kein Spaghetti-Code, kein wildes Draufloshacken mehr, sondern Vorüberlegungen und Modularisierung waren angesagt. Der Umstieg von TP auf Delphi 3 fiel mir dann schon etwas leichter, obwohl auch hier zahlreiche Hürden zu überwinden waren.

Zudem hab ich hier und in anderen Delphi-Foren bereits sehr viele Hinweise darauf, was an meiner eigenen Programmierweise fehlerhaft ist (z.B. FreeAndNil, vor vielen Jahren die Boolean-Geschichte [if MyBool = false then], richtiges Erzeugen und Freigeben, zu Datenbanken, OOP, Objektlisten usw.), erhalten. Das hat mir zu zahlreichen Aha-Erlebnissen verholfen. Ich kann es daher nur begrüßen, wenn hier wie andernorts so wenig wie möglich – am besten gar kein – Quick&Dirty-Coding empfohlen wird. Daß sich mancher, der in seinen Kreisen als Programmierer und gilt oder sich für fortgeschritten und der Grundlagen mächtig einschätzt, dabei hin & wieder auf den Schlips getreten fühlt (Grundlagen beherrsche ich – aber was ist ein Parameter, was ein Backslash, eine Methode?), läßt sich meiner Einschätzung nach nur schwer bis gar nicht vermeiden. Das hat letztlich gar nichts mit Programmieren zu tun, dafür umso mehr mit der menschlichen Eitelkeit.