fpreport

[af0815]

Nachdem fpreport ein Interessantes, aber noch nicht wirklich fertiges Produkt ist, fange ich diesen Thread an um Fehlendes, Fehler, Bugfixes, Fragen zu diskutieren.

Eine gewisse Diskussion hat schon hier stattgefunden https://forum.lazarus.freepascal.org/in ... #msg342177 . Allerdings fällt es mir leichter manche Dinge zuerst in der Muttersprache auszudrücken.

@MacWomble: Kannst du vielleicht den Code oder den Report hier einstellen mit dem du das Problem in der Schrift erzeugt hast.

Falsche Berechnung Textteile

Anmerkung 2019-12-19 070542.jpg (80.51 KiB) 3654 mal betrachtet

Im fpreport bereich Memo, wird der Text in Teile zerlegt um den entsprechend der Vorgaben in das Memo ein zu passen. Nachdem dabei auch ganz wenige HTML Befehle (bold und italic) möglich sind werden diese auch extra behandelt. Dazu werden einfach die passenden Schriftarten heraus gesucht. Dann wird anhand des Textes die nötige Breite und Höhe bestimmt. Da wird allerdings vergessen, das bei den HTML Befehlen, die aktuel verwendeten Fonteigenschaften nicht gültig sind, sondern die speziellen. Das war offensichtlich schon bewusst, allerdings auf später verschoben, wie man dem Kommentar dort entnehmen kann. Ich habe den Teil mal IMHO sinnvoll gefixt.

Ich würde gerne damit testen um zu sehen ob es wirklich was gebracht hat und ob die Berechnung jetzt korrekt ist.

[MacWomble]

Klar, kein Problem

Vielleicht noch ein paar Hinweise:
Der Aufbau des Reports ist etwas getrickst, aber nicht unlogisch. So fungiert z.b. das DetailData-Band als Master für die Subdetails. Da ich die Daten im Moment aus CSV-Daten ziehe, muss die Anzeige der Subdetails unterdrückt werden, wenn diese nicht zum Detail gehören. Alles ist aber in den Properties nachvollziehbar.

Ich denke mir, dass das ganze eleganter machbar wäre, wenn Json mitsamt Strukturen verwendbar wäre. Die Json-Datei müsste dann zwar umfangreicher geparst werden, aber es ließen sich bestimmt daraus dann mehrere Datasets (aus einer json-Quelle) für fpreport generieren und verwenden.

Ich habe auch bereits einige Experiment mit deinem Patch angestellt und konnte noch nichts finden, was da nicht passen sollte - Nochmals Danke!

[af0815]

Danke, der Patch funktioniert, dank deiner Dateien kann ich das gleich Testen. Achtung du musst natürlich auch den ReportDesigner neu kompilieren (nicht nur den FPC bzw. die Komponenten)!!

Ich werde alles zusammenfassen und als Patch einreichen


Bugreport 0036459 -> https://bugs.freepascal.org/view.php?id=36459

Edit: Ist mit trunk 43701 gefixt.

[af0815]

Vielleicht noch ein paar Hinweise:
Der Aufbau des Reports ist etwas getrickst, aber nicht unlogisch. So fungiert z.b. das DetailData-Band als Master für die Subdetails. Da ich die Daten im Moment aus CSV-Daten ziehe, muss die Anzeige der Subdetails unterdrückt werden, wenn diese nicht zum Detail gehören. Alles ist aber in den Properties nachvollziehbar.

Ich habe es noch nicht ganz begriffen. Der erste Schritt für mich wäre, wenn JSON und CSV gleich funktionieren würden. Daher das Beispiel auch mit JSON gehen würde.

Aktuell habe ich das JSON Dataset mal als Komponente für Lazarus rausgezogen und in der IDE installierbar gemacht. Da wird einen schon viel klarer, wo aktuell die Grenzen sind. Das ist nur als Container designed, nicht als aktive Komponente mit Dateizugriff. Das ist (aus nachvollziehbaren Grund) nicht enthalten. Mal sehen was sich daraus ergibt.

Die angehängt Komponent ist nur für Studienzwecke geeignet und ist aus den Sourcen der FCL entstanden. Damit hat man in Lazarus das TJSONDataSet visuell zur Verfügung und sieht auch, wie spartanisch das ausgeführt ist.

[af0815]

@MacWomble: Du hast im englischen Forum bezüglich Expressions gesucht.
Hast du dir schon die unit rptexpressions im Verzeichnis Demos vom fpreport (FPC) selbst angesehen ?! Der liebe Graeme hat dort in den Beispielen den Report immer per Programm erstellt, allerdings kann man das direkt auf den ReportDesigner übertragen.

Edit: Typo entfernt

[MacWomble]

Danke, werde ich mir noch anschauen.

[MacWomble]

Ich habe mir das Beispiel von Graeme angesehen, aber das ist recht einfach aufgebaut und spiegelt kaum die wirkliche Anforderung eines Reports wie z.b. einer Rechnung.

Was ich noch nicht gefunden habe ist:
1. Auf jeder Seite benötige ich unten die Seitensumme der Details der Seite und auf der Folgeseite entsprechend den Übertrag.
Für mein Verständnis sollte dies mit Variablen funktionieren, nur finde ich nicht den richtigen Weg.
Die Summenvariable sollte also im Pageheader sowie im Pagefooter angezeigt werden können.
2. Wie funktioniert die Aggregatfunktion bei Variablen
3. Wie bzw. wo weise ich einer Variable Werte zu oder addiere diese auf?
4. Besser wäre aber, wenn man den Detailheader und Detailfooter seitenbezogen anzeigen könnte, was von der Sache
her richtiger wäre.
Bisher erscheint der Detailheader (also die Überschriften) nur vor der ersten Detailposition und der Footer nach der letzten.
Da der Header z.B. die Überschriften der Spalten beherbergt, sollte dieser auf jeder Seite anzeigbar sein, auf der noch Positionen
gedruckt werden!
5. Woher kommt das Problem, dass in einem Memotext nur 256 Zeichen ausgegeben werden? Hat das eventuell mit meinen
CSV-Dateien zu tun?
6. Wie kann ich Zahlen so formatieren, dass statt des Dezimalpunktes ein Dezimalkomma gesetzt wird?

Vorstellung eines Rechnungsaufbaus:

- Seitenkopftext (Rechnungskopf mit Absender, Logo und Anschrift) (nur auf erster Seite)
--- Rechnungskopftext und Auftragsbezogene Daten (nur auf erster Seite)
----- Überschrift der Rechnungspositionen (ab 2. Seite zusätzlich mit Summen-Übertrag der vorherigen Seite)
----- Rechnungspositionen
------- SubDetails zur Rechnungsposition
----- Summenzeile der Rechnungspositionen (nicht auf letzter Seite)
bzw. Summenzeile der Rechnungspositionen mit Summe, Steuer, Anzahlung, Zahlbetrag (nur auf letzter Seite)
--- Rechnungsfusstext mit Auftragsbezogenen Daten und Zahlungsbedingung etc. (nur letzte Seite)
- Seitenfusstext mit Seitenangabe (Seite x von y) (auf jeder Seite)

[af0815]

Ich habe mir das Beispiel von Graeme angesehen, aber das ist recht einfach aufgebaut und spiegelt kaum die wirkliche Anforderung eines Reports wie z.b. einer Rechnung.

Der gute Graeme ist ein excellenter Programmierer, ich fürchte aber das er ein schlechter Buchhaltungsschreiber ist
Ok, deine Aufstellung ist verständlich, mal sehen, was ich dazu noch in den Sourcen finde. Kannst du bitte ein Beispiel machen und als Anmerkung hineinschreiben, wo was nicht so läuft. Für mich ist es leichter mit etwas bestehenden zu arbeiten und zu suchen, wo es krankt.

[MacWomble]

Im Prinzip bezieht sich das auf den Report, den du bereits hast. Für die d.Preis-Felder sollen Summen gebildet werden, der Rest ist im letzten Post beschrieben.

[af0815]

Danke für die Info.

Aktuell habe ich noch ein Problem, das ich auf 64Bit Systemen den Reportdesigner nicht bauen kann, da einige ppu's nicht erzeugt wurden. Der Grund dürfte im bau vom FPC liegen. Dort waren bei 64 Bit nicht alles freigeschalten, das wurde behoben, allerdings vermute ich das, die makefiles nicht neu erzeugt wurden und somit einige Dateien nicht übersetzt werden. Ich habe das Packagebuild System vom FPC nicht ganz begriffen. Da suche ich noch, es ist mir deswegen auch wichtig, da ich dadurch Patches im System relativ rasch selbst fixen und kompilieren kann, ohne jedesmal den FPC neu bauen zu lassen.

[MacWomble]

Komisch, dass du mit dem originalen Lazarus da Probleme hast. Bei mir ging das auf Anhieb.
Da ich nicht direkt Lazarus verwende, kann ich dir da leider nicht behilflich sein.
Das einzige, was ich hierzu beitragen kann ist die von mir verwendete FreePascal 3.3.1 Source 10-12-2019 SVN Rev 43670

[af0815]

Baue ich eine Win32 Version so geht es. Nur die 64 Bit macht Probleme, da ursprünglich fpreport für 64 Bit deaktiviert gewesen ist. Da gab es Probleme in einem anderen Package - nicht fpreport selbst, sondern von dort stark verwendet - das wurde behoben und fpreport freigeschalten. Ich vermute nur stark, das die makefiles nicht neu erzeugt wurden. Das sollte auch kein Problem sein, wenn man weis wie es geht

[MacWomble]

Anmerkung zu fpreport: Der Name fpReport ist denkbar ungünstig, weil es den Namen in anderen Bereichen (ausserhalb fpc) bereits mehrfach gibt (z.B. bei Epson, im Sozialwesen, Foreign Policy Report usw.). Das macht die Suche nach Informationen schwer.

[wp_xyz]

Und wo ist das Problem, noch ein Wort in die Suchmaske aufzunehmen, das die Auswahl einscrhänkt? Etwa "fpreport pascal"?

[af0815]

BTW: wenn fpreport geändert gehört, dann auch Lazarus, das scheinbar sehr stark im Pflegebereich vertreten ist