FPReport csv

[MacWomble]

Ich möchte fpReport hier keinesfalls schlecht machen, aber ich muss meinem Unmut etwas Raum verschaffen:

Unter einem Reporter verstehe ich:
1. Einen Designer, mit dem ich Reports für die vom Programm, csv oder der DB bereitgestellten Daten einen Report designe und abspeichere.
2. Einen Previewer, der den geöffneten Report genau so anzeigt, wie er auch gedruckt wird
3. Einen Exporter, der den aufbereiteten Report genau so abspeichert, wie er gedruckt wurde (z.B. pdf)

Bei fpReport scheint nur in PDF der Druck so dargestellt zu werden, wie es im Designer eingestellt wurde.
Im Preview werden HTML-Befehle (z.b. bold) nicht dargestellt. Der Druck weicht von der PDF auch deutlich ab.
Das ist aber kein wirkliches Problem, wenn man generell pdf erstellt und die pdf dann speichert/druckt.

Eigentlich dachte ich, der fpReport habe die Aufgabe, etwas (nämlich die Druckausgabe) zu vereinfachen.

So wie das ganze aufgebaut ist, scheint mir das weit am Ziel vorbei zu gehen.
Seit über einer Woche experimentiere ich nun bereits an der Druckergeschichte herum, ohne ein wirkliches Ergebnis zu haben.

Klar, kann man aus dem Designer die Informationen erhalten, welche benötigt werden, aber wenn ich doch bereits einen Report mit
den Datendefinitionen habe, sollte doch mit zwei, drei Zeilen ein Ausdruck desselben möglich sein
So funktioniert es i.d.R. bei allen Reportern wie FastReport, List&Label etc., sogar bei lazReport (leider wackeliger Designer und keine Schriftattribute im Memofeld):

Daten für den Report bereitstellen (SQL, CSV oder ein oder mehrere Objectlisten)
Report laden
Report mit den Daten gemäß der enthaltenen Definitionen aufbereiten
Report nach PDF o.ä. exportieren

Hier dann noch mit Streams und jsonparser und Konstrukten wie 'Move(ms.Memory^,uts[Low(uts)],Length(uts));' hantieren zu müssen
um die bereits definierten Daten dann auch tatsächlich zu bekommen, finde ich absolut unglücklich gelöst.

Es kann ja sein, dass ich einfach nicht verstehe, wie da was mit dem anderen zusammenhängt und hier mein Unmut herrührt.
Es kann auch sein, dass ich das alles falsch interpretiere, aber das ist auch der (bisher) unzureichenden Dokumentation geschuldet.

Bereits vor 40 Jahren habe ich z.B. Reports auf HP MDT im Quelltext erstellt, was damals schon wesentlich einfacher war.
Und da musste teilweise für Grafiken noch jede einzelne Nadel des Nadeldruckers angesprochen werden...

So, jetzt habe ich meinem Frust Luft gemacht und schließe mit:

fpReport ist nach FastReport (zu teuer und nicht quelloffen) der einzige Reporter, der das kann, was ich benötige.
Deswegen werde ich weiterhin versuchen, meine Reports mit fpReport umzusetzen.
fpReport ist ein Reporter, welcher noch in eine frühen Stadium steckt und weiter entwickelt wird. Das lässt auf entsprechende Funktionalität hoffen.

P.S. Sollte das, was ich mir vorstelle mit fpReport einfacher machbar sein - und ich habe es nur nicht gesehen, so bitte ich um Richtigstellung.

[af0815]

Mein Verständnis zu fpreport:
fpreport ist grundlegend ein bandbasierende Reportengine. Dazu noch grundlegend verwendbar OHNE Abhängigkeiten zu visuellen Komponenten. Das ist deswegen wichtig um zB. Reports auf einem headless Server machen zu können. Deswegen auch die Unterteilung in Reportengine, Renderer und Designer. Wobei der Designer eher eine AddOn für Lazarus ist und nicht als Hauptargument.

Renderer: Der für PDF kann am besten die Einheiten umsetzen, das ist auch meine Erfahrung. Der für die LCL ist nur so stark wie die Umrechnung und Positionsbestimmung im Widgetset funktioniert. Ich habe mich aufgrund eines Bugs beim RasPi im gtk2 Widgetset damit sehr intensiv herumschlagen dürfen (BugID 35973). Deswegen habe ich mir etwas an gefährlichen Halbwissen zu fpreport aneignen dürfen

Designer: Der ist ein AddOn nur für Lazarus und sicher nicht so verbreitet Ich mache meine bisherigen Reports aus dem Code heraus, deswegen habe ich auch nicht soviel Erfahrung damit. Zusätzlich war schon das mit den Datenquellen, Designer und im laufend Code eine Herausforderung bei Delphi, je nach Engine

Reportengine: Die hat sicher auch noch Luft nach oben, wie du gemerkt hast, aber durch Fixes und Erweiterungen so wie von Dir, wird das sicher stabiler und besser. Auch die gängigen Grafiken wie TAChart etc. sollten nativ besser gekoppelt werden können. Ich habe dort auch ein paar Sachen entdeckt Ich kenne fpreport allerdings von der ersten Stunde an.

Zusätzlich gibt es noch die Datenanbindung Die ist auch für mich noch noch wirklich griffig. Da habe ich noch zu lernen. Zusätzlich kann die aktuell SQLdb. Da bleibst du mit Zeos vermutlich noch aussen vor. Das was bei dir Probleme macht, ist das grundlegend nicht vorgehen war die Datenanbindung in den Report aufzunehmen. Das wurde nur für den Designer dazugestöpselt, deswegen ist auch der Weg ein wenig unglücklich für dich gelöst.

Du hast also KEINEN Reporter, so wie du ihn verstehst und möchtest. Das Design macht auch absolut Sinn, wenn man sich die Stücke einzeln vor Augen hält und bedenkt das der major Renderer pdf ist und das ganze ein FPC Projekt und kein Lazarus Projekt ist.

LazReport, FastReport,... haben einen ganz anderen Aufbau und sind visuell ausgerichtet.

[MacWomble]

Ich sehe in fpReport auch sehr viel Potential für die Zukunft, nur ist der Einstieg ungewohnt schwierig.

Was das Rendern angeht, so meinte ich das im letzten Post schon so, dass PDF im Prinzip der richtigste Weg ist. Sowohl am Bildschirm, wie auch in den Ausdrucken sieht alles identisch aus, egal auf welcher Plattform. Ein zusätzliches Preview ist überflüssig, wenn es die Daten anders darstellt.

Dass fpReport FPC und von Lazarus losgelöst ist, stellt im Prinzip kein Problem dar. Das sehe ich eher als Vorteil der Engine.

Reports direkt im Quelltext zu erstellen, ist in manchen Fällen sicherlich ausreichend, macht das ganze dann aber unflexibel.
Beispiel bei mir aktuell Adressetiketten/-listen:
Ich habe keine Ahnung davon, welche Etikettengröße und Art der Anwender einsetzt. Dies muss dieser im Report selbst bestimmen können. In den Listen soll der Anwender bestimmeen können, welche Daten in welcher Reihenfolge in die Zeilen sollen. Das funktioniert ja soweit auch mit fpReport und dem Designer.
Später benötige ich Datenblätter, Rechnungen etc. Alles ist Anwenderspezifisch in Bezug auf das Layout.
Das einzige, was ich vorgeben kann, sind letztendlich die notwendigen Daten.
Ein fest im Quelltext abgelegter Report ist hier absolut zwecklos.

Die Unterteilung in die unterschiedlichen Aufgabenbereich Daten, Layout, Rendern und Exportieren finde ich auch gut, allerdings mangelt es hier hauptsächlich an der entsprechenden Dokumentation.

Beispiel ist mein Report für Adressetiketten aus CSV-Daten.
Mit dem Designer (standalone) kann ich alles, was hierfür notwendig ist, realisieren und auch im Report speichern und auch wieder laden.
Die Daten werden erneut aus der CSV ausgelesen und richtig verarbeitet.
Den Report aber im eigenen Programm zu laden, die Daten bereitzustellen und das ganze - ohne Designer und Preview - als PDF zu exportieren, scheint jedoch eine Wissenschaft für sich.
Im Designer-Quelltext habe ich aber einen Kommentar entdeckt, welchen ich bisher nicht wirklich bedacht hatte, der aber absolut logisch ist:
Um irgendetwas mit einem Report zu machen, müssen die Daten bereits vorliegen!
D.h. der erste Schritt ist die Datenaufbereitung, dann das Design bzw. das Rendern.

Was die Datenaufbereitung angeht stelle ich mir vor, CSV-Dateien für einfache Berichte verwenden zu können. Das sind einfache Listen, Etiketten etc. Die Daten werden oft ohnehin neben dem Bericht noch als CSV benötigt.
Was komplexere Bericht (Master-Detail etc) angeht (aber auch für einfache Berichte möglich ist), gibt es zum einen die direkte Anbindung an die Datenbank. Auch diese Konfiguration wird im Report hinterlegt und funktioniert mit dem Designer so weit recht gut.
In meinem Projekt arbeite ich aber nicht direkt mit der Datenbank, sondern über Objektlisten, welche die Datentabelle abbilden. Ich denke, hier könnte man eventuell auch TBufDataset einsetzen, um die Verbindung zum Report zu vereinfachen - aber gelöst habe ich das auch noch nicht.
Übrigens funktioniert fpReport auch gut mit anderen Datenbanken wie Firebird. MariaDB etc. - nur eben ohne Zeos, was aber m.E. keine Einschränkung darstellt.

Was die übrigen Reportprogramme angeht: Fortes hat keinen (User-)designer, die anderen können keine Textattribute in Memos darstellen. Ich benötige aber zwingend die Möglichkeit, einzelne Worte in einem Text fett darzustellen. In fpReport geht das mit HTML-Tags. Unterstreichen soll auch gehen, habe ich aber nicht hin bekommen (ist für mich aber auch nicht so wichtig). Bei FastReport geht das vermutlich auch nicht, zumindest habe ich im Onlinedesigner und in der Dokumentation nichts gefunden. Allerdings kann FastReport RTF (ich arbeite aber hauptsächlich unter Linux).

So, jetzt bin ich durch und wieder am Anfang
Wie es funktioniert, habe ich verstanden, wie es geht, noch nicht
Aber wenn das mit der Datenanbindung erst mal gelöst (verstanden und umgesetzt) ist und mit gespeicherten Reports funktioniert (der Designer kann es ja), bin ich ein gutes Stück weiter...

P.S: Und so kurz vor Weihnachten: Ich wünsche mir für den fpReport noch so vieles

[af0815]

Schau dir mal die TFPReportObjectlist an

Code: Alles auswählen

 
lReportData := TFPReportObjectlist.Create; 
lReportData.List := MyTFPObjectlist;
 
.....
p := TFPReportPage.Create(FReport);
p.Data := TFPReportData(lReportData);
 
 

Damit hast du bereits Daten für den Report. Die du einfach an den Report bindest. Das ist so genial geil. Weil die Listen kann man einfach in mehreren Ebene sortieren (wenn mann es weis wie - lol)
Für die Header verwende ich Report Variablen.

Obiges ist mal kurz aus einem Projekt herausgesucht.

Übrigends mit dem Report zur Laufzeit erzeugen, habe ich den Vorteil keine Reportdateien mit zu liefern zu müssen. Ausserdem ist der Report Modular aufgebaut und ich kann die Blöcke per Programm zusammenstellen lassen.

Zum Thema Rendern auf einem Panel (TFPReporterExportCanvas) habe ich auch noch eine gute Zeile gefunden

Code: Alles auswählen

 
...
FReport.RenderReport(rptExporter);
...
TFPReportExportCanvas(rptExporter).GetCurrentPageRenderSize(Breite, Hoehe);
MyPanel.Height:= Hoehe + 10;
...
invalidate;
 

Man kann damit den Renderer Fragen, wie groß das Ergebnis ist und dann das Panel entsprechend zu verändern. Damit sieht das Preview schon ähnlicher dem Ausdruck aus.

[MacWomble]

Mit den Reportdateien hast du natürlich Recht und in manchen Fällen mag das ja ausreichen, den Report in der Unit zu definieren. In meinen Anwendungen benötige ich aber mehr 'Freiheit'.

Die Objektliste habe ich auch im Blick, da dies sehr gut zu meinem Projekt passt. Ich arbeite ja auch mit Objektlisten...
Was mir hierbei nicht ganz klar ist, sind die verschiedenen Datenebenen. Du weist die Daten der Page zu. Sind diese damit auf den Bändern verfügbar?
Ich habe gelesen, dass die Daten von Beginn an den jeweiligen Bändern zugeordnet werden müssen. Das wäre natürlich nicht optimal, da hierdurch Flexibilität und Funktionalität verloren geht.
Daten, welche sich im Report nicht ändern (z.B. Anschrift, Rechnungskopf etc.), funktionieren sicherlich als Variablen, aber ganz richtig ist das wahrscheinlich nicht.
Für mein Verständnis dienen Variablen in der Hauptsache der Summenbildung und ähnlichem (so ist es zumindest bei allen anderen Reportengines).
Hier benötigt man einen Master und mindestens ein Detail mit eventuellen Subdetails. Das habe ich mir aber noch überhaupt nicht angesehen.
Normalerweise sollte die Datenstruktur so sein:

Reportdaten (Reportheader, Reportfooter)
-- Seitendaten (Pageheader, Pagefooter)
---- Masterdaten (z.B. Rechnungskopf)
------ Detaildaten (z.B. Rechnungspositionen)
-------- (Subdetaildaten)
------ (Detaildaten)
-------- (Subdetaildaten)

Ich kann mir aber auch vorstellen, die Daten zuvor als json aufzubereiten, dann ist die Struktur bereits enthalten. Es würde dann auch nur ein "Datensatz" zu übergeben sein.
Wenn ich fpReport richtig interpretiere, sollte das hiermit machbar sein.

[af0815]

Frage:
verwendest du Github bzw. hast ein Konto dort ? Zusatz: Verwendest du GIT ?

[MacWomble]

Nein, habe nur lokales svn auf meinem Server

[af0815]

Schau mal auf https://github.com/afriess/fpReportSamples

Da habe ich mal dein csv-Problem gelöst im Beispiel 02. Wenn du keinen Git hast, kannst du das trotzdem als Download herunterladen. Unter windows gehören die üblichen dll's ins bin-Verzeichnis, damit die kompilierten Programme laufen.

Ich habe mal die Beispieldaten von dir genommen, ich hoffe ich habe dazu deine Erlaubnis

[MacWomble]

Wow ! Klasse !

Herzlichen Dank, das funktioniert wie gewünscht. Und sieht auch nicht kompliziert aus.
Ich schaue mir das später noch genauer an, aber so hat das ganze doch wirklich Sinn.