fpreport

[af0815]

Im trunk sind die Installationsprobleme von 64 Bit jetzt soweit gefixt.

Der expressionparser hat Probleme und auch sonst laufen die Demos in fcl-report nicht komplett sauber. Mal sehen was ich auf dem Mailingliste bewirken kann.

[MacWomble]

Nachdem ich nun wieder einen Tag damit verbracht habe, die Struktur der Reports von fpreport zu verstehen, ist mir etwas weiteres aufgefallen, was meines Erachtens notwendig ist. Ich fasse hier nochmals alles zusammen:

1. Der Detailheader sowie der Detailfooter muss auf jeder Seite des Reports ausgegeben werden können. Ansonsten scheint ein Erstellen von sinnigen Rechnungen derzeit nicht möglich zu sein.
Hintergrund: Bei einer Rechnung über mehrere Seiten muss die laufende Summe unter den Details ausgegeben werden, auf der Folgeseite entsprechend der Übertrag (nach den Detailüberschriften) über der ersten Position.

2. Es sollte eine Möglichkeit geben, im Report zu prüfen, ob die aktuell ausgegeben Seite die letzte Seite mit Detaildaten ist.
Eine Prüfung wie PageNo=PageCount ist hier nicht ausreichend!
Hintergrund: Dies ist zur Anzeigensteuerung der Summen notwendig.

3. Memofelder (zumindest aus csv) werden nach 256 Zeichen abgeschnitten oder nicht komplett eingelesen.

4. Das was ich mit meinen csv-Dateien mache, sollte auch mit einer (einzelnen) json-Datei möglich sein.

5. Die Grafik wird mehrfach im Report gespeichert, obwohl es immer die selbe ist. Optional sollte man nur die Pfadangabe zur Grafik speichern können (Auswahl Link oder einbinden).
Hintergrund: Es könnte passieren, dass ein reportfile unnötig aufgebläht wird.

6. Bei png sollte Transparenz unterstützt sein, generell wäre auch SVG wünschenswert.

7. Es sollten Summen gebildet werden können, d.h. den Variablen sollten Werte zugewiesen werden können.
Hierfür ist eventuell einfaches Scripting (in Lazreport gut gelöst) notwendig.

Die folgenden sind nicht ganz so wichtig:

8. Elemente und Bänder sollten mit copy/paste (Reportübergreifend) handlebar sein.

9. Eine angefügte Seite lässt sich nicht wieder löschen.

Ich hänge in der Anlage noch meinen aktuellen (Spiel-) Report an. Achtung: Der Reportdesigner muss in den Ordner kopiert werden, sonst stimmen die Pfade nicht (Ich habe die Pfadangaben im Report gelöscht).

Meine Meinung derzeit zu fpReport:

Es gibt noch einige wichtig Sachen, welche realisiert werden müssten. Dann jedoch wäre ein sehr guter, wirklich brauchbarer Reporter für Lazarus endlich Realität. Es wäre bedauerlich, wenn fpReport das gleiche Schicksal zuteil würde, wie den vorhandenen Mitspielern.
Für einfache Reports ist fpReport derzeit bereits sehr gut einsetzbar, aber für die Erstellung von Auftragsunterlagen wie Angebote und Rechnungen fehlen die oben genannten Punkte leider noch.
Eine Funktion für Etikettendruck könnte ich mir ebenfalls noch vorstellen, diese wäre sogar relativ simpel:
Ein Dialog frägt ab, ab welchem Etikett gedruckt werden soll. Entsprechend werden 'leere Details eingefügt' ...
Ich mache das tatsächlich derzeit über leere Datensätze, da die Abfrage vor der Datenaufbereitung im Programm stattfindet.
Generell kann ich die Reports nicht in meinen Units erzeugen, da hierdurch die flexibilität, welche ich benötige, verloren geht.

[af0815]

Aktuell habe ich ein paar Probleme in Angriff genommen, die beim Testen der Demos im Sourceverzeichnis von fcl-Report aufgetreten sind.

Es gibt Problem bei den Fonts mit denen gearbeitet wird. Das Demo fcldemo -d jsondata -f pdf ist bei mir unter Windows gar nicht gelaufen, sondern mit einer Exception abgebrochen. Das ist für mich teileweise gefixt. Aber im Trunk ist noch keine Lösung

Das Demo fcldemo -d expressions -f pdf hat nicht funktioniert,weil sich der Expressionparser geändert hat. [RecNo] hat gar nicht funktioniert. Ist im Trunk bereits gefixt.

---------
zu Punkt 7: Unter Lazarus funktioniert es bei mir nicht in einen Report Expressions einzufügen. Damit kann ich auch aktuell keine Zwischensummen erzeugen. Ganz verstehe ich den Expressionparser noch nicht, aber das wird noch werden (müssen).
Aktuell sollten die Variablen auf Gruppe, Seite oder Spalte zurückgesetzt werden können. Der Expressionparser sollte das hinbekommen.

zu Punkt 3: Ist in einem Demo von dir sowas versteckt ? wei dann kann ich mal nachsehen wo abgeschnitten wird. Ich habe da so eine Vermutung.

zu Punkt 4: Aktuell sehe ich da nichts, da es dann ein Filebasierendes Dataset für JSON geben muss. Das jetzige hat absolut keinen Dateibezug. Wenn dann kann ich mir vorstellen, wie bei csv das in verschiedenen JSON Dateien.

zu Punkt 6: Die Grafik ist im Renderer nicht allzu komplex. Die Frage ist nur wie bringt man Transparenz ins pdf.

zu Punkt 5: Grafiken können in einer Datei. Sieht man auch im Demo von Lazarus. Nur der Designer kann das scheinbar nicht.

Code: Alles auswählen

  With TFPReportImage.Create(TitleBand) do
    begin
    Layout.Left := 0;
    Layout.Top := 0;
    Layout.Width := Memo.Layout.Height;
    Layout.Height := Memo.Layout.Height;
    Stretched:=True;
    LoadFromFile(ExtractFilePath(ParamStr(0))+TESTIMAGE);
    end;
 

[MacWomble]

zu 3.
Ja, alle Positionstexte und auch Rechnungskopf und Fuß sind abgeschnitten (siehe m.csv=> m.Rechnungskopf, m.Rechnungsfuss und d.csv => d.Beschreibung)

zu 4.
wenn ich meine Sorcecodeexkursion nicht falsch interpretiere, werden auch die csv intern in json gehandelt. Es müsste also auch möglich sein, eine strukturierte json in einfache jsons (wie bei den einzelnen csv) umzuwandeln.

zu 6.
keine Ahnung, ob da konkret etwas zu beachten ist. Aber die Transparenz geht ja bereits im Editor sowie im Preview nicht.

Generell habe ich einfach alles notiert, was noch notwendig wäre. Mit dem Quellcode komme ich nicht wirklich klar, das ist mir eine (oder ein paar mehr) Nummer(n) zu hoch ...

[af0815]

zu 4. es wird immer auf die nativen Datasets zurückgegriffen. json ist nur die Beschreibung was verwendet wird. ist genaugenommen eine Factory.

zu 3. deswegen vermute ich das es da ein default gibt. Weil es macht keinen Sinn das abzuschneiden. Die routinen für das memo sind für lange Texte vorbereitet. Da gehe ich von einer alten Einschränkung bei csv aus.

[MacWomble]

ich finde die Stelle nicht, wo die Daten aus der csv gelesen werden.

Ich wollte versuchen, ob das mit dem Abschneiden auch bei json passiert, aber
mit Datenfiles im json-format kommt bei mir nur eine Access Violation wenn ich den Preview aufrufe ...
=> Das passiert übrigens auch, wenn ich die countries.json aus den Beispielen in einem neuen Report verwende!

[af0815]

Ich habe mal das nackte TFSONDataset Quick and Drirty in eine installierbare Komponnete gebracht. Da sieht man, das genaugenommen nichts geht. Das ist kein allgemeines Dataset wie die anderen. Aktuell hat es nur den Sinn den Report speichern zu können.

[MacWomble]

Ich schau mir die json-Geschichte später noch an. In der Zwischenzeit habe ich getestet, ob der Text auch abgeschnitten wird, wenn er aus der Datenbank kommt - wird er aber nicht. Somit könnte man das Problem mit dem Abschneiden zunächst als weniger wichtig einstufen.

Dabei ist mir aber ein weiterer Fehler begegnet:
Texte aus MySQL werden nicht richtig gelesen, wenn sie aus Text, Tinytext, Mediumtext oder Longtext-Feldern kommen. Hier scheint für Text nur VARCHAR() möglich zu sein.
Nicht so schlimm wenn man dies beachtet, aber ein Fehler ist es dennoch.

Also beides Probleme, welche sich umgehen lassen und somit vertagt werden können.

Bleiben als wichtigste Probleme die Punkte 1,2 und 7, ohne deren Lösung komplexe Reports scheitern.

[af0815]

ich finde die Stelle nicht, wo die Daten aus der csv gelesen werden.

Die grundlegende Definition wird hier getroffen.
fpreportdatcsv -> function TCSVReportDataHandler.CreateDataset(AOwner: TComponent; AConfig: TJSONObject): TDataset;

Es wird bei unseren Demos allerdings die Option FirstLineAsFieldNames verwendet. Wenn ich das jetzt in Lazarus ausprobiere, so werden automatisch die Feldgrößen auf 255 gesetzt. Mehr ist nicht vorgesehen und hat nichts mit dem fpReport zu tun.

Wenn man das nicht will, so muss man die Felder händisch definieren und als type ftMemo verwenden, dann gehen auch große Felder.

[MacWomble]

Ok, das klingt logisch.

Aber da gibt es noch was - Hab's noch nicht getestet, finde ich aber auch nicht gut, hier einen größeren Wert zu setzen.

in fpreportdatacsv ab Zeile 70:

Code: Alles auswählen

function TCSVReportDataHandler.CreateDataset(AOwner: TComponent; AConfig: TJSONObject): TDataset;
 
Var
  C : TMyCSVDataset;
  A : TJSONArray;
  I : Integer;
 
begin
  C:=TMyCSVDataset.Create(AOWner);
  C.CSVOptions.FirstLineAsFieldNames:=AConfig.Get(keyFirstLineHasFieldNames,DefFirstLineFieldNames);
  C.CSVOptions.Delimiter:=AConfig.Get(KeyDelimiter,defDelimiter)[1];
  C.CSVOptions.quoteChar:=AConfig.Get(KeyQuoteChar,defQuoteChar)[1];
  if not C.CSVOptions.FirstLineAsFieldNames then
    begin
    A:=AConfig.Get(keyCustomFieldNames,TJSONArray(Nil));
    If Assigned(A) then
      For I:=0 to A.Count-1 do
        C.FieldDefs.Add(A.Strings[i],ftString,255); // <====== hier ist eine Begrenzung auf 256 Zeichen
    end;
  C.ReadOnly:=True;
  C.CSVFileName:=AConfig.Get(KeyFileName,'');
  Result:=C;
end;
 

[af0815]

Gerade getestet:

Ad 9: Gehe links in den Objektbaum, wähle die Page aus, anschließend auf Menü->Edit->Delete Selection und die Page ist weg.

[MacWomble]

Gerade getestet:

Ad 9: Gehe links in den Objektbaum, wähle die Page aus, anschließend auf Menü->Edit->Delete Selection und die Page ist weg.

Jepp, kann ich bestätigen.

[MacWomble]

So, hier der richtige Ansatz für die Einstellung der Stringlänge:

Im Dateneditor kann man die Feldnamen bei csv definieren. Hier sollte es auch möglich sein, den Typ und die Größe zu definieren.
Zusätzlich sollte eine Auswahl dazu (Checkbox) 'Supress first line'

Alternativ könnte man auch die Felder aus der CSV hier anzeigen und die Definition der Größe zulassen.
(Also bei 'First line has field names')

Mookup.png (42.61 KiB) 2961 mal betrachtet

[af0815]

der Type ftString ist mit max 255 definiert. Genaugenommen würde hier ftMemo hingehören, dann ist es aber kein String mehr

Edit: Ja würde korrekt sein.

[MacWomble]

Dann würde ja die Eingabe des Typs reichen und die Size könnte wegfallen ...

Edit: Dann wäre es analog zu json-Daten, wobei es auch dort den Typ Memo nicht gibt !