fpreport

[af0815]

uuuiii, es würde da einen bösen Hack möglich machen.

Code: Alles auswählen

TCSVOptions = Class(TCSVHandler)
  private
    FDefaultFieldLength: Word;
    FFirstLineAsFieldNames: Boolean;
  Public
    Constructor Create; override;
    Procedure Assign(Source : TPersistent); override;
  Published
    // Does first line of the file contain the field names to use ?
    property FirstLineAsFieldNames : Boolean Read FFirstLineAsFieldNames Write FFirstLineAsFieldNames;
    // Default is to create all fields as strings with the same length. Default string field length.
    // If the CSV dataset has field defs prior to loading, this is ignored.
    property DefaultFieldLength : Word Read FDefaultFieldLength Write FDefaultFieldLength;
    // Field delimiter
    property Delimiter;
    // Character used to quote "problematic" data
    // (e.g. with delimiters or spaces in them)
    // A common quotechar is "
    property QuoteChar;
    // String at the end of the line of data (e.g. CRLF)
    property LineEnding;
    // Ignore whitespace between delimiters and field data
    property IgnoreOuterWhitespace;
    // Use quotes when outer whitespace is found
    property QuoteOuterWhitespace;
  end;
 

Man könnte den DefaultFieldLength ja auch dazunehmen, dann kann man ja den Wert größer machen

[MacWomble]

Ja, nur sollte die Defaultfieldlength nicht generell vergrößert werden, sondern die Größe sollte für jedes Datenfeld anpassbar sein.

Ich habe mal versucht herauszufinden, warum json-Daten nicht gehen. Dabei bin ich in fpreport bis hier gekommen:

Code: Alles auswählen

procedure TFPReportData.Open;
 
begin
  if IsOpened then
    exit;
  if Assigned(FOnOpen) then
    FOnOpen(Self);
  DoOpen;      // Hier wird der Fehler (Access Violation) gemeldet, IsOpened is False
  InitFieldDefs;
  FIsOpened := True;
  FRecNo := 1;
  If not EOF then
    InitFieldValues(false);
end;                                    

Irgendwie hat der die json-Datendatei nicht geöffnet ...

[af0815]

Zur Information, da fpreport sehr stark die fpexpression verwendet. Hier https://bugs.freepascal.org/view.php?id=36525 hat MvC entschieden, das der fpexpressionparser keine Lokalisierung erhält. Das bedeutet auch, das es Auswirkungen geben wird, da die ganzen Formeln, Ausdrücke in den Feldern betroffen sind. Auch die Gruppierungen können davon betroffen sein. Bei meinen letzten Versuchen mit dem fpReportdesigner bin ich schon über diese Problematik gestolpert, besonders da ich eine csv Datenbank gehabt habe, die natürlich die Daten mit einem Komma als Dezimalseperator gehabt hat.

Mal sehen was da noch herauskommt.

[wp_xyz]

Mir scheint es, dass Michael Van Canneyt die Problematik um die Lokalisierung in meinen ExpressionParser-Patch nicht ganz verstanden hat... Vielleicht habe ich den Report auch etwas zu allgemein geschrieben. Ich denke, wenn ihr ihm ein explizites Beispiel zeigen könnt, wo das Problem im FPReport auftritt (mit Hinweis auf den Bug-Report), könnte er es sich nochmals überlegen.

[EDIT]
Ich habe gerade im fcl-report/src Verzeichnis gesehen, dass sich dort eine unit fprexprpars.pp befindet, das ist mehr oder weniger eine Kopie der Standard-Unit fpexprpars aus dem Verzeichnis fcl-base, wahrscheinlich, um so leichter Anpassungen einbauen zu können, die man für FPReport braucht, aber in dem "allgemeinen" Parser nicht haben möchte. Das musste ich auch bei FPSpreadsheet so machen. Ist eigentlich ein Zeichen von schlechtem Klassendesign, wenn man zu sowas gezwungen ist. Aber vielleicht kann man den Lokalierungspatch hier einpflegen und so für FPReport leichter verfügbar machen.

[af0815]

Was mich am meisten aktuell stört, ist das die Unit tests aus dem Verzeichnis /test auch nicht sauber durchlaufen. Das zeigt mir, das die nicht verwendet werden, da es ansonsten im Buildprozess auffallen sollte. Ich will die Unit tests eigentlich erweitern um auch andere Sachen klar zu machen und in den Bug report eintragen zu können.

@wp, ich kann dir nur zustimmen. Das mit der Kopie des Expressionparser ist mir noch nicht bewusst gewesen.

Ich habe mich allerdings auf den Unit test und den Report Designer fokussiert. Im Unittest schlägt unter anderen ein Unit test fehl, weil eben die MvC-Methode verwendet wurde. Wir konvertieren zwangsweise mitz einem Dot und Testen dann gegen ein Komma im Unittest. Macht natürlich auf PCs mit dot als Dezimaltrenner kein Problem, auf einen PC mit einem Komma aber schon. Deswegen bin ich darauf im fpreport gestoßen.

Jetzt sind die Ferien leider vorbei und ich darf mich wieder mehr um die Firmensachen kümmern. Da fpreport quasi ein Hobby von mir geworden ist

[wp_xyz]

@wp, ich kann dir nur zustimmen. Das mit der Kopie des Expressionparser ist mir noch nicht bewusst gewesen.

Wie user "Pascal" im englischen Forum mitteilt, war das nur eine Übergangslösung und wird per Versionscheck nur in älteren FPC-Versionen verwendet.

[af0815]

Die unittests sind gefixt worden. die laufen jetzt einmal durch.

Das blöde ist nur, das es definitiv so ist, das fpreport nur mit Punkt als dezimaltrenner arbeiten soll. Das per design von MvC so. Was ich schon gesehen habe, wenn ich eine csv Datei einlese, die für uns richtig die Zahlen formatiert hat, das ich da in Probleme komme, wenn ich einfach die Werte in Variablen einfüllen will. Ich warte aktuell ab, was Pascal noch zusätzlich alles wieder in Lot bringt, bezüglich der Reports mit Variablen. Er dürfte da auch einiges an Aha-Erlebnisse gehabt haben. Aber das ist eine andere Geschicht aus dem englischen Forum und dem Bugtracker.