[fpSpreadsheet] Fehler beim Schreiben von Formel

[Soner]

Hallo,
beim Schreiben einer Formel in ein TsWorksheet taucht Fehler.
Die Formeln sind okay, weil wenn man es als Text einfügt und in Zelleditor oben bearbeitet, dann wird es automatisch in Formel umgewandelt, dann erscheint aus das Ergebnis.
Kennt jemand eine Lösung?

Ich habe das Programm beigefügt.
Bildschirmfotos von Fehler:

Fehler1

err1.jpg (13.93 KiB) 351 mal betrachtet

Fehler2

err2.jpg (12.56 KiB) 351 mal betrachtet

[Soner]

Vergeßt was ich unten geschrieben habe, Komma-Fehler erzeuge ich in der Formel mit Format selber.
Ich glaube es hat mit Zahlenformat zu tun. Ich habe aus obere Formel "if" entfernt:

Code: Alles auswählen

aSh.WriteFormula(rc+1,cc+2,'=ROUND((('+svsumcell+'*'+Format('%.2f', [PDKVSATZ])+')/100);2)');

Ergebnis ist das:
=ROUND(((E53*7,30)/100);2)

Und jetzt taucht der Fehler:
Expected riht bracket at position 15, but got ,.

Der Fehler liegt beim Koma von 7,30.

Ich weiß nicht, warum die Zahl als deutsche Zahlenformat übergeben wird, obwohl bei WriteFormula lokalisation als Vorgabe false ist:
function WriteFormula(ARow, ACol: Cardinal; AFormula: String;
ALocalized: Boolean = false; R1C1Mode: Boolean = false): PCell; overload;

Es scheint, es gibt ein Bug bei WriteFormula.

[Soner]

Jezt ist Formel so(ich habe Nachkommastellen bei Format 0 gemacht):
=ROUND(((E53*7)/100);2)

Danach wird das Semikolon vor der Zwei als Fehler "Unknown Charakter" gemeldet.

Muss man beim Formeleinfügen irgendetwas machen?

[paweld]

in Formeln ist das Dezimaltrennzeichen der Punkt und das Wertetrennzeichen das Komma

Code: Alles auswählen

procedure TForm1.FormCreate(Sender: TObject);
var
  aSh: TsWorksheet;
  rc, cc, aRSumTab, arsum: Integer;
  svsumcell, BeitrBemGrCell, BeitrBemGr: String;
  Beitragsbemessungsgrenze, AVSatz, RVSatz, PDKVSATZ, PDPVSATZ: Double;
  fs: TFormatSettings;  //<-- Add this
begin
  fs.DecimalSeparator := '.'; //<-- Add this
  WbkSrc1.FileName := ''; //<-- leere Name erzeugt auch Workbook.  WbkSrc1.CreateNewWorkbook;
  aSh := WbkSrc1.Workbook.AddWorksheet('testsh1');

  aSh.WriteText(1, 1, 'Scrolldown to line 53');
  aSh.WriteColWidth(0, 3.71);
  aSh.WriteColWidth(1, 2.8);
  aSh.WriteColWidth(2, 2.8);
  aSh.WriteColWidth(3, 6);
  aSh.WriteColWidth(4, 6);
  aSh.WriteColWidth(5, 6);
  aSh.WriteColWidth(6, 6.8);
  aSh.WriteColWidth(7, 7.86);
  aSh.WriteColWidth(8, 8);
  aSh.WriteColWidth(9, 6.8);

  PDKVSATZ := 7.3;
  PDPVSATZ := 0.6;
  Beitragsbemessungsgrenze := 4987.5;
  AVSatz := 1.3;
  RVSatz := 9.3;
  aRSumTab := 43;
  arsum := 41;
  
  aSh.WriteText(aRSumTab + 3, 1, 'Bearbeitet als Text eingefügte Formeln in Formeleditor oben, am Ende etwas hinzufügen und wieder löschen, Enter drücken,');
  aSh.WriteText(aRSumTab + 4, 1, 'dann wird der Text in Formel umgewandelt und man sieht, dass die Formeln richtig sind.');
  aSh.WriteText(aRSumTab + 5, 1, 'Fehler sind bei F53 und G53');
  WshtGr1.Col := 1;
  WshtGr1.Row := aRSumTab;
  
  rc := aRSumTab + 8;
  cc := 3;
  aSh.WriteNumber(arsum + 2, 8, 5137);
  svsumcell := 'E' + (rc + 2).ToString;
  BeitrBemGrCell := 'C' + (rc + 2).ToString;
  BeitrBemGr := Format('%.2f', [Beitragsbemessungsgrenze], fs); //<--
  aSh.WriteNumber(rc + 1, cc - 1, Beitragsbemessungsgrenze);
  aSh.WriteFontSize(rc + 1, cc - 1, 7);
  aSh.WriteText(rc, cc, 'Sachbezüge');
  aSh.WriteFontSize(rc, cc, 7);
  aSh.WriteNumber(rc + 1, cc, 0);
  aSh.WriteFontSize(rc + 1, cc + 1, 7);
  aSh.WriteText(rc, cc + 1, 'SV-Brutto');
  aSh.WriteFontSize(rc, cc + 1, 7);
  aSh.WriteFormula(rc + 1, cc + 1, '=D' + (rc + 2).ToString + '+I' + (arsum + 3).ToString); //bei formel rc+1+1 weil excel mit 1 anfängt
  aSh.WriteText(rc, cc + 2, 'KV');
  aSh.WriteFontSize(rc, cc + 2, 7);
  aSh.WriteText(rc, cc + 3, 'PV');
  aSh.WriteFontSize(rc, cc + 3, 7);  
    
  aSh.WriteFormula(rc+1,cc+2,'=ROUND(((IF('+svsumcell+'>'+BeitrBemGr+','+BeitrBemGr+','+svsumcell+')*'+Format('%.2f', [PDKVSATZ], fs)+')/100),2)');  //<--
    
  aSh.WriteFormula(rc+1,cc+3,'=ROUND(((IF('+svsumcell+'>'+BeitrBemGrCell+','+BeitrBemGrCell+','+svsumcell+')*'+Format('%.2f', [PDPVSATZ], fs)+')/100),2)'); //<--
end;     

[wp_xyz]

Es ist leider etwas komplizierter: Man muss unterscheiden, ob man nur per Code mit fpspreadsheet arbeiten will, oder mit den visuellen Controls.

• Im Code-Fall gilt das, was paweld geschrieben hat: Als Dezimaltrenner den Punkt und als Argumenttrenner das Komma - das ist Programmierarbeit, und da sind diese nunmal so üblich.
• Schreibt man dagegen ein Programm mit visuellen Spreadsheet-Controls, kommt der User ins Spiel, der vielleicht die von anderen Programmen (und von der Schule) her gewöhnten Trennzeichen verwenden will. Dann werden beim manuellen Editieren von Zellinhalten im Grid oder im CellEdit die FormatSettings des geladenen Workbooks ausgewertet, und die haben in Deutschland standardmäßig das Komma als Dezimaltrenner und als Argumenttrenner (ListSeparator) den Strichpunkt. Wenn du lieber Punkt und Komma willst, kannst du bei passender Gelegenheit, ab besten nach dem Laden der Datei oder spätestens im OnSelectEditor-Event des Grid, sWorksheetGrid.Workbook.FormatSettings.DecimalSeparator und .ListSeparator entsprechend umdefinieren. (Achtung: das ist keine globale Einstellung, sondern muss bei jedem Workbook wiederholt werden; im Abstand von ein paar Jahren betrachtet, vielleicht etwas unpraktisch...).

[wp_xyz]

Ich weiß nicht, warum die Zahl als deutsche Zahlenformat übergeben wird, obwohl bei WriteFormula lokalisation als Vorgabe false ist:
function WriteFormula(ARow, ACol: Cardinal; AFormula: String;
ALocalized: Boolean = false; R1C1Mode: Boolean = false): PCell; overload;

Es ist nur eine Frage des Standpunkts. Das ALocalized sagt nicht aus, dass die Zahlenstrings lokalisiert werden sollen, sondern ob sie lokalisiert sind. Das ist eine wichtige Information für den Parser, denn er muss bei lokalisierten Zahlenstrings den Dezimaltrenner aus den Formatsettings des Workbook nehmen, andernfalls wäre es einfach der Punkt.

Ob die Strings lokalisisiert sind, legst du selbst fest. Wenn du die Formel selbst, so wie in dem Beispiel von paweld zusammenbaust und dabei explizit einen Punkt als Dezimaltrenner einsetzt (fs.DecimalSeparator := '.'), dann sind sie nicht lokalisiert, d.h. du kannst die Eingabe der Parameter von WriteFormula nach dem Formelstring beenden, weil ALocalized standardmäßig false ist. Wenn du aber im Zusammenbau der Formel keine lokalen Formatsettings verwendest, dann wird der Zahlenstring ein Komma als dezimaltrenner enthalten, und dann muss in WriteFormula nach dem Formelstring ein TRUE für ALocalized stehen, damit der Formelparser damit klarkommt.

[Soner]

@paweld, @wp_xyz
Danke, es war die Lösung, ich wäre nie drauf gekommen als Trenner Komma zu benutzen.
Villeicht sollte man das in Quelltext über der Funktion WriteFormula schreiben.

Ich weiß nicht, warum die Zahl als deutsche Zahlenformat übergeben wird, obwohl bei WriteFormula lokalisation als Vorgabe false ist:
function WriteFormula(ARow, ACol: Cardinal; AFormula: String;
ALocalized: Boolean = false; R1C1Mode: Boolean = false): PCell; overload;

Es ist nur eine Frage des Standpunkts. Das ALocalized sagt nicht aus, dass die Zahlenstrings lokalisiert werden sollen, sondern ob sie lokalisiert sind. Das ist eine wichtige Information für den Parser, denn er muss bei lokalisierten Zahlenstrings den Dezimaltrenner aus den Formatsettings des Workbook nehmen, andernfalls wäre es einfach der Punkt.

Danke für die Erklärung, den Fehler hatte ich mit Format selbst erzeugt. Ich übergebe jetzt an die Funktion-Format temporäre "Formatsetting" mit Punkt als Dezimaltrenner und es funktioniert wie gewünscht.