Konvertierung Fast-Report Formate

[miboe]

Hallo und Guten Morgen,

gibt es einen einfachen und für den normalen Averp-Anwender gangbaren Weg, Formulare die noch im alten FastReport 2.x Format sind auf das neue FastReport 4 Format umzustellen OHNE den ganzen Report neu zu designen?

Gruß
Michael

[martin.h]

Hallo

ich denke das wäre viel wert, weil der Fastreport [alt] eine unmögliche *.pdf Engine hat. [gefühlt < 80 dpi..]....

so "fast" finde ich den übrigens nicht, wie der Name klingt, ein Druckseitenaufbau ist nicht gerade sehr schnell

[markus.fuger]

Hab vor einiger Zeit auch schon mal danach gesucht und damal wenig bis nichts gefunden:
google spuckt das aus:
FR2 -> FR3
http://www.fast-report.com/en/forum/ind ... topic=2865
(kann aber leider nicht sagen ob die Version 3 files kompatibel mit v4.0 sind)

FR2.5 -> FR4
http://www.fast-report.com/en/forum/lof ... t6415.html

Das betrifft aber nur den FastReport Teil der AvERP Report Dateien, dann muss mal halt auch noch sehen ob bei dem AvERP Teil was zu machen ist.

SG
Markus

[miboe]

Hallo,

es geht ja gezielt um den Fastreport-Teil Der zweite Deiner Links scheint mir in Averp nicht zu funktionieren, da dort in den .RES eines Druckformulars der Fastreport-Teil bei FR2.5 als binärer Müll drin steht. Bei den "neuen" Formularen mit FR4 ist der eigentliche FastReport-Code als Klartexte vorhanden. Damit fallen die Textkonvertierungen also leider flach ...

Den ersten Link (das mit den Rechtsklick und dann Import) werde ich mal versuchen. Delphi oder ähnlich habe ich nicht, sodaß der Teil mit der frx2xto30, den ich schon mehrfach gesehen hatte, ausscheidet. Es scheinen aber auch noch viele reine FR-User das Problem zu haben, wenn man bei denen ins Forum schaut

Gruß
Michael

[admin]

Wir hatten uns das angeschaut und aufgegeben. Die Programme, die FR anbietet, funktionieren nicht wirklich umfassend. Die Konvertierung aller bestehenden Reports und des Grid-Druck-Deigners schieben wir daher auch schon eine Weile vor uns her.

Wenn jemand hier eine Lösung hat, die nicht "Neuerstellen" lautet, dann sind wir ganz Ohr.

[miboe]

Dann mache ich mal folgenden völlig selbstlosen Vorschlag: jedes Formular, welches ich für uns ab sofort umstelle und das noch Standard ist, stelle ich dann hier zur Verfügung. Wenn der ein oder andere sich dem anschließen kann, kriegen wir ja vielleicht was zusammen.

Ich hatte zwischenzeitlich echt die von FR beschriebenen Versuche mit der Trial-Version gemacht und war mir nicht sicher, ob die mit Ihren Tips im Forum den Leuten wirklich helfen oder einen Härtetest durchführen wollten

Gruß
Michael

[markus.fuger]

Hallo,

ich habe mich jetzt noch einmal etwas damit gespielt und bin gemischter Hoffnung, dass die Konvertierung von FR2 nach FR4 in AvERP funktioniert.

Mein Vorgehen:
Download von
http://www.fast-report.com/pbc_download ... verter.zip
http://www.fast-report.com/pbc_download/fr3demo.exe
http://www.fast-report.com/pbc_download/fr4demo.exe

Öffnen zweier representative Reports mit AvERP Design (FRDBADRAD.RES (Adresseetiketten) und FRDCMRESMB_NEU.RES (Rechnung neu)) und habe sie sowohl im AvERP Designer gesperichert (C:\Programme\AvERP\Masken) und auch mit dem Fast Report Designer (*.frf).
Wenn man sich nun die beiden Files anschaut und für die *.frf Datei einen Hexeditor verwendet (z.B. Hexedit Plugin für notepad++) stellt man fest, dass bis auf zusätzlich 8 Bytes (ev. Größeninfo) in der *.RES Datei der Binärteil gleich ist.

Nun habe ich beide Dateien mit dem FR3Convert (3. Tab) in *.fr3 File konvertiert.

Wenn man diese Files nun direkt mit dem FR 4 Demo öffnet, stellt man fest, dass die meisten Informationen verloren gegangen sind.
Öffnet man die Datei allerdings mit FR 3 Demo speichert sie unter einem neuen Namen und dann mit dem FR 4 Demo, so bleibt "alles" erhalten.

Wie eingangs erwähnt, funktioniert das allerdings nicht bei allen Files. So hatte ich bei dem Formular FRDBADRAD Glück und es ging fehlerfrei, das Formular FRDCMRESMB_NEU.RES welches sicher zu den komplizierteren in AvERP gehört, aber nicht (oder nur teilweise).
Es machte hier wie auch bei ein paar anderen die ich teste Fehler beim Seitenfuß.

Leider habe ich derzeit weder die Zeit um diesen Prozess zu automatisieren
- Auslesen der Druckformulare aus der DB
- Feststellen der Bedeutung der ersten 8 Bytes
- Binärteil in temp File schreiben
- mit der Prozedur fr2xto30.pas die wahrscheinlich in FR3Convert (http://www.fast-report.com/en/forum/ind ... topic=3719) verwendet ist convertieren
- und dann noch einmal mit dem FR3 Designer öffnen und speichern

Damit könnte man einmal abschätzen wie viele Formulare wirklich davon betroffen sind, bzw. welches Feature nicht kompatibel ist. Und diesem vielleicht auf andere Wege Herr werden.

SG
Markus

[markus.fuger]

Lösung für das Problem mit nicht geladenen Bändern:

Da es sich bei den *.fr3 Dateien um xml Dateien handelt und die Values von den Parametern anscheinend keine ß (ev. auch ä,ö,ü) haben dürfen, habe ich kurzerhand in der *.fr3 Datei alle Vorkommen von ß,ä,ö,ü durch ss,ae,oe,ue (und natürlich auch die Großbuchstaben) ersetzt.

Danach wieder zuerst mit FastReport 3 öffnen und speichern und dann "einfach" mit FastReport 4 öffnen.

Die Bänder usw. sind halt zum Teil etwas anders positioniert, dass kann man aber entweder manuell, oder falls man eine Systematik erkennt ev. leicht programmatisch in den XML dateien ändern!

Hoffentlich konnte ich dazu beitragen den Fortschritt AvERP <-> FR4 (FR5?) etwas zu beschleunigen.

SG
Markus

[markus.fuger]

Hab mich nun noch etwas weiter herumgespielt und folgendes herausgefunden:

Nehmen wir an der FastReport2 Abschnitt in der *.RES Datei beginnt mit

180000005CBA010018FFFFFFFF0F0048502032353030432053657269657300FFFFFFFFFF090000....

und ist insgesamt (ohne Leerzeichen und Zeilenumbrüche) 226.504 Zeichen lang
Der Teil der in der *.RES und der durch den Designer exportierten Datei gleich ist, ist um 16 Characters kürzer (also 226.488 Zeichen) - startet also
18 FF FF FF FF 0F 00 48 50 20 32 35 30 30 43 (fetter Teil von oben)

Nehmen wir nun von diesem hex Code die ersten 8 Bytes (=16 Character in der *.RES File - kursiv von oben)
18 00 00 00 5C BA 01 00
und nehmen an, dass die Bytes 5,6,7 (sehr wahrscheinlich auch 8 aber ein so kompliziertes Formular hatte ich nicht) die Länge des nachfolgenden Formulars darstellt (in Little Endian 5C BA 01 00), so entspricht das in der "für den Menschen gewöhnlicheren (=big Endian)" schreibweise 00 01 BA 5C was aber dezimal nichts anders ist als 113.244, also genau die Hälfe der noch zu lesenden Zeichen.

Mit dem Wissen sollte es für den geübten Programmierer ein Leichtes sein, ev. so einen Konverter zu schreiben

SG und gutes Gelingen,
Markus

[UliS]

Dann mache ich mal folgenden völlig selbstlosen Vorschlag: jedes Formular, welches ich für uns ab sofort umstelle und das noch Standard ist, stelle ich dann hier zur Verfügung. Wenn der ein oder andere sich dem anschließen kann, kriegen wir ja vielleicht was zusammen.

Ich hatte zwischenzeitlich echt die von FR beschriebenen Versuche mit der Trial-Version gemacht und war mir nicht sicher, ob die mit Ihren Tips im Forum den Leuten wirklich helfen oder einen Härtetest durchführen wollten

Gruß
Michael

Hallo PowerAvERPUser Michael,

selbstlose Vorschläge bergen das Risiko, das nach demPrinzip "Kleiner Finger - ganze Hand" unverschämt nach gefragt wird, ob den in der Umsetzung nach FastReport4 bereits das Standard-Rechnungsformular in der Logik von FRDCMRESMB_NEU enthalten ist?

Kann aus eigenrer Schöpfung nur relativ exotische Beiträge FR4-Beiträge leisten:
-Ersatzteiletiketten mit FirmenLogo
-Typenschild aus Fertigungsauftrag in Abhängigkeit von der Seriennummer
-Kalkulationsblatt aus Arbeitsstammplan
mit dem Ziel den Excel-Export aus FR4 zu nutzen
-Studie über Produktetiketten mit EAN-Codes und Chargen

[markus.fuger]

Hallo AvERP Benutzer!

Gibt es schon Fortschritte auf der FastReport 4 Front?

Wenn nein, möchte ich folgenden Weg vorschlagen:
-) Kurzes Script, dass alle Druck Reports aus AvERP ausliest und lokal als *.RES Datei abspeichert + parsing des Report Abschnitts und ablegen als FR2 kompatible Files. (ev. Python)

-) Batch Konvertierung mit dem von FastReport zur Verfügung gestellten Skripts FR3Convert

-) Suchen und ersetzen von nicht ASCII konformen Charactern (ev. Python)

-) habe einmal vor einiger Zeit in c't von einem Tool gelesen, dass auf das GUI von Windows Programmen zugreifen kann: AutoIt
http://www.autoitscript.com/site/autoit/
Damit ein Script erstellen, dass alle Files mit FR3 Demo öffnet und wieder speichert

-) Zum Schluss noch ein kurzes Script, dass die alten *.RES Dateien nimmt und die notwendigen Ersetzungen für FR4 vornimmt und wieder abspeichert (ev. Python)

-) zippen und hier im Forum zur Fehlerkorrektur/Weiterverarbeitung zur Verfügung stellen

Was haltet ihr davon - wer könnte mitmachen, wenn noch nichts ähnliches existiert, möchte ich ab Mai damit beginnen - Mithilfe erwünscht!

SG
Markus

[markus.fuger]

Hallo!

PROOF OF CONCEPT:

Habe gestern etwas in die Tasten geklopft und einige der Punkte implementiert.

Also das Python Script erledigt folgende Dinge:
- es holt sich alle "alten" FR2 Reports aus der DB und speichert den Report Teil Binär ab

- (noch ein manueller Schritt - sollte später AutoIt erledigen) Konvertierung von FR2 nach FR3

- es sucht nach allen deutschen Umlauten und ß und ersetzt sie - und speichert das Ganze ab

- (todo - mit AutoIt): öffnen und speichern der FR3 Datei mit dem Fast Report 3 Demo Tool

- (todo - mit AutoIt): öffnen und speichern der FR3 Datei mit dem Fast Report 3 Demo Tool

Wenn also jemand hier mit AutoIt oder einem ähnlichen Tool umgehen kann bitte melden!

Weiters möchte ich noch folgende Dinge implementieren:
- Da die meisten User vielleicht noch andere Druckformulare angelegt haben ein einfaches GUI mit dem man die zu konvertierenden Reports auswählt werden.

- wie ihr an den Files vom Anhang seht, sind durch das FastReport eigene Tool (fr2x-fr3converter) die contents der Bänder meist leicht nach unten verschoben und befinden sich daher nicht mehr im Band. Möglicherweise findet man einen Zusammenhang und kann das durch Programmierung beheben.

- der Rest der *.RES Datei gehört noch FR4 kompatibel geändert - um eine AvERP Designer kompatible File zu erzeugen. Hier wäre ich für einen Input von Synerpy dankebar - vielleicht könnte jemand in kurzen Regel erläutern was sich ändern muss

Für alle die nicht mehr warten können:
Ich habe eine zip Datei mit allen konvertierten Reports angehängt.
!ACHTUNG! : Diese können aber nicht direkt mit dem AvERP Designer geladen werden. Diese gehören zuerst mit dem Fast Report 3 Demo geöffnet und gespeichert (siehe oben) und können dann erst mit dem Fast Report 4 geladen werden. !ACHTUNG!

Für alle die mitentwickeln wollen:
Das Python Skript ist angehängt.
Wurde nur unter Windows getestet und setzt folgendes Package voraus:
http://pypi.python.org/pypi/firebirdsql/0.3.4

Schöne Grüße,
Markus

[markus.fuger]

PS: hab nicht gefunden wie man hier im Forum ein attachment anhängen kann - daher hier die Links zu meinem Webspace:

Konvertierte Report (bitte zuerst mit FR3 öffnen und speichern, bevor diese mit FR4 geöffnet werden)
http://www.fuger.at/files/markus/FRDConverter/FR3.zip

Python Skript:
http://www.fuger.at/files/markus/FRDCon ... nverter.py

[miboe]

Hallo ...

das neue Release sorgt ja immer wieder für Motivation, sich auch nochmal mit unliebsamen Themen auseinanderzusetzen, was ich dann am Wochenende auch mal getan habe. Das Ergebnis war nur so bescheiden, daß ich die Baustelle, von der wir hier reden, mittlerweile für mich persönlich als "nicht machbar" einstufe. Warum? Lesen Sie hier weiter ...

Ich habe in Anlehnung an Markus Ausführungen, das ganze mal manuell Schritt für Schritt mit ganz einfachen Formularen nachvollzogen und Schwachstellen abgeklopft.

1. Altes Formular als frf auslesen, geht prima manuell im ReportDesigner über die Funktion "Speichern unter. Ich habe angesichts der Probleme, die Markus mit Umlauten hatte vorher im Designer die Bänder und Elemente auf die problematischen Zeichen abgesucht und wenn notwendig umbenannt. Mit dem Objektexplorer geht das prima, da sieht man ja alle Namen im Flipdown untereinander. Umlaute in Feldbezeichnern kann es keine geben, da die sich ja auf SQL beziehen, wo es auch keine Umlaute in Feldnamen gibt. Umlaute in Strings machen keinen Stress und können stehen bleiben wie sie sind.

2. Formular mit dem FR2 zu FR3 Converter von FastReport konvertiert ohne Fehler und Probleme

3. Formular nacheinander mit FR3Demo und FR4Demo geöffnet und unter anderem Namen (zur Nachvollziehbarkeit, notwendig ist das aber sicher nicht) gespeichert. Dabei habe ich nichts am Formular gemacht, sondern wirklich nur öffnen und dann speicern unter ...

Ab hier gingen dann die Probleme los
4. Bestehendes Formular in Averp auf bNewFastRep umgestellt gespeichert und aus AverpDesign raus. Druck des Formulars in Averp liefert leere Seite OHNE Fehlermelduzngen. Wer hätte es geahnt. Soweit das gewünschte Verhalten

5. Designer starten, Formular auswählen und im Reportdesigner bearbeiten. Es öffnet sich ein leerer FR4 Report. Auch soweit das erwartete Ergebnis. ABER Den Versuch, Datenquellen zuzuweisen quittiert AverpDesign häufig mit einer Zugriffsverletztung. Manchmal auch nicht. Hier hat man also schon das erste ernste Problem.
Lösungsansatz: die RES Datei extern bearbeiten und unter DATASETS <> die Datenquellen manuell eintragen

6. In den leeren Report die fr3-Datei reinladen. Optisch passiert genau was man will, aber in der Regel hat man sofort wieder das Problem mit den Datenquellen, die man nicht aktivieren kann. Auch hier hilft der Ansatz von Punkt 5

7. Dann ist aber endgültig das Ende der Fahnenstange erreicht: durch die Konvertierung mit den externen Tools von FR haben ALLE (in Worten ALLE) Bänder und Memo's ihren Bezug zu Datenquelle und Feld verloren. Sprich, selbst wenn in einem Memo z.B. [q_rep1."MASKENKEY" drin steht nutzt einem das nichts. Denn zum einen hat FR die Verknüpfung zur Datenquelle extern verloren und zum anderen heißen im FR4 die Datenquellen nicht mehr q_rep1 sondern in dem Fall frx_rep01. Und es gibt keinen MASS-EDIT alle "Suchen&Ersetzen"

8. Richtig interessant wird es aber dadurch, daß die Adressierung von Feldern nicht mehr einheitlich ist in FR4: in Memo können sie wie früher direkt über [] angesprochen werden. In Funktionen und vor allem in den Event-Prozeduren werden sie aber über <> kenntlich gemacht. Tolle Erfindung sowas ... Selbst wenn es also einen Massedit gäbe für Memos und ihren Inhalt könnte man ihn nicht verwenden, denn sobald ein adressiertes FEld nicht direkt Inhalt des Memo ist, sondern über eine Funktion ausgewertet wird, muss das FEld mit <> anstattt [] angesprochen werden. Und NUR dort

9. Kleiner Lichtblick: wenn man sich bis hierher durchgekämpft hat, ist das bearbeiten des Codes der Eventhandler in FR4 sehr viel einfacher, da es den Reiter CODE gibt, auf dem man dann doch per "suchen&ersetzen" sich helfen kann. Man muß halt nur an so Kleinigkeiten denken wie die Deklaration von Variablen, die in FR2 nicht notwendig war, in FR4 aber schon. Und man muß auch daran denken, daß die Seitensteuerung völlig anders funktioniert. Hier hilft Averp (besser FR4) aber sehr schön, da beim Drucken Fehler im Code mit Zeile und Spalte genau angegeben werden. Sehr elegant. Immerhin

10. hier hatte ich keine Lust mehr ... denn nachdem ich alle vorhergehende Schritte wirklich irgendwie hinbekommen hatte hat Averp dann bei 1 von 3 Formularen mit denen ich rumgemacht hatte, schließlich beim Drucken nur noch kommentarlos eine Zugriffsverletzung ohne Hinweis auf die wirkliche FEhlerquelle gezeigt. Wahrscheinlich war das dann doch wieder die Baustelle mit Datenquellen nicht erkennbar ...

Und das Schlimme: ich hatte das mit Minimalformularen wie Artikeletiketten und sowas getestet. Also Kinderkram verglichen mit einer Rechnung oder einer Bestellung.

Wenn jemand dann doch noch eine wirklich gute Idee hat, vielleicht auch einen Hinweis, was ich übersehen habe, bin ich ganz Ohr. Ansonsten kapituliere ich vor der Baustelle als "Generalaktion".

Gruß
Michael

[SYN20]

Hallo miboe,

5 + 6. Nach FR4 konvertieren Druck über Designer laden, speichern und Designer komplett schließen und wieder öffnen. Anschließend sollten sich die Datenquellen für den Report auswählen lassen.

7. Eine Möglichkeit die Datenquellen automatisch zuordnen zu lassen habe ich leider nicht gefunden. Also ja, das muss manuell vorgenommen werden. Ein Austausch des Inhalte der Memos mit dem einfachsten Fall '[q_rep1."MASKENKEY"]' wäre allerdings über einen Texteditor möglich.

8. Im Code kann man vollständig über suchen&ersetzen arbeiten.
'[q_' durch '[frx_'
'"]' durch '">'
'rep1' durch 'rep01', ... , 'rep9' durch 'rep09'

10. Es gibt Laufzeitfehler, bei denen Fr4 leider nicht die Fehlerquelle angibt. Das wären z.B. Vergleiche von Blobtexten mit Strings wie <frx_rep12."BLOB_TEXT"> <> '' oder Verwendung der Eigenschaft HideZeros bei nicht numerischen Feldern. Um die Fehlerquelle wenigstens ansatzweise zu lokalisieren kann man

Code: Alles auswählen

if (Debug) then ShowMessage(Sender.Name);

in die FR4-Prozeduren einbauen und bei Bedarf aktivieren.

Ich würde Ihnen gerne eine einfache Möglichkeit à la 'Klicken Sie dort auf Play' aufweisen, aber momentan gibt es diese nicht. Bisher ist die Konvertierung nicht ohne Aufwand durchführbar.

Gruß,
Syn20