Inoffizielles deutsches Xbase-Forum

Also wenn ich die Beiträge hier so lese, tendiere ich immer mehr dazu zu L&l zu wechseln.
In Potsdam ist ja dazu eine Session geplant (leider fehlt die Übersicht der Session auf der Seite Forentreffen).
Die ganzen Bemühungen um den Quellcode, etc. haben ja nichts gebracht und was der neue Kompatibilitätsschalter
für negative Auswirkungen hat ist wohl noch relativ unbekannt.

Wäre es nicht einfacher, wenn jemand ein Konvertierungstool von FR3 auf L&L Reports erstellt.
Mir ist nicht bekannt ob das praktikabel wäre, aber bevor ich mich x Tage hinsetze und die Reports
neu erstelle, zahle ich doch lieber für so ein Tool.

Koverhage hat geschrieben:und was der neue Kompatibilitätsschalter für negative Auswirkungen hat ist wohl noch relativ unbekannt.

nö, die sind eindeutig bekannt !

1. Alaska hat intern bei einigen Typen die Verarbeitung geändert, weil "das für z.B. Unicode ... nötig ist"
2. Der Schalter schaltet diese Erweiterungen ab.

Aus meiner Sicht ist eindeutig, dass der Schalter für die Übergangszeit (zu etwas anderem) eingebaut wurde um aktuell ein Programm umstellen zu können.
Wer darauf setzt dass dies auch in Zukunft geht ...

gibt es eigentlich eine Dokumentation, wie FRAX die Reports speichert ?

Das sind ganz normale XML Dateien (Dateiendung FR3)

Die Frage ist ob man das lesen kann was was bedeutet (Linie von da bis da ..., Felder etc.)
Wenn ja, sollte zumindest ein Interpreter möglich sein ...
Hast du ein Beispiel aufgeteilt nach :

1. Nur Linien, vielleicht LOGO (als PNG Datei oder so)
2. Das Formular von 1. mit Einzeldaten (wie z.B. Anschriftsfeld) als Feld oder Fix vorgegeben
3. Das Formular aus 2. mit Zeilendaten (wie z.B. Rechnungspositionen)

Wenn ja, lass es mir zukommen und sehe ob ich da was zu meiner Printerklasse hinbekomme (kann aber dauern).
Wenn der Interpreter steht, kann ja ein anderer das Zielsystem wie L&L übernehmen.

Ich habe die Testversion von FRAX erhalten und finde dort zwei Dateien:

FASTDEMO.CH
FASTDEMO.PRG

und den Hinweis, dass man FASTDEMO.OBJ dazu laden muss.
Ich frage mich gerade, wenn man diese beiden als Quellcode hat, wo genau kommen dann die Probleme her ?

FRSyst.dll

ist dies eine "angepasste" FastReport DLL, die intern auf das Xbase++ C-API zugreift ?

Wenn es eine normale C / Pascal DLL ist, müssten doch normale Aufrufe machbar sein, so wie QuickPDF ja auch aufgerufen wird.
Kennt sich damit jemand aus ?

Ich habe mir die FR3 Beispiele "Einfache Liste" und "Gruppierung" angesehen und zumindest diese sollten leicht mit Xbase++ Druckmitteln erzeugbar sein (Ich würde natürlich meinen HBPrinter nehmen).
Allerdingst wird in beiden Fällen ja direkt auf die DBF zugegriffen, etwas das ich gar nicht mag. Es gibt im designer aber auch die ADO Schnittstelle, die müsste doch weiterhin funktionieren oder ?

Spätestens bei der OLE Einbindung von Grafiken und komplexen Operationen ist aber mit der Nachbildung Schluß, insbesonder weil ich ja KEIN Frax User bin

Wie ist eure Zielrichtung ?

1. Xbase++ drucken, sich selbst um Daten kümmern und nur die FR3 Dateien lesen ?
2. FRAX eventuell mit ADO weiternutzen (was ja dann eher eine einfache FastReport Nutzung und ein ADO zu Xbase++ Problem wäre) ?
3. FR3 nach L&L Format umsetzen ?

Falls jemand die "Designer" insbesondere für seine Kunden benötigt, ist 1. zu wenig ... hätte jemand Interesse die FR3 zu zerlegen ?

Kannst Du aus der Zielrichtung eine Umfrage machen ?

Falls jemand die "Designer" insbesondere für seine Kunden benötigt, ist 1. zu wenig ... hätte jemand Interesse die FR3 zu zerlegen ?

Was meinst Du damit ?

Koverhage hat geschrieben:Kannst Du aus der Zielrichtung eine Umfrage machen ?

gerne, obwohl du das auch gekonnt hättest, da es ja DEIN Thread ist

PS: nur im ersten Beitrag eines Threads kann man eine Umfrage starten, auch nachträglich durch ändern.

Koverhage hat geschrieben:
Falls jemand die "Designer" insbesondere für seine Kunden benötigt, ist 1. zu wenig ... hätte jemand Interesse die FR3 zu zerlegen ?
Was meinst Du damit ?

Davon den Aufbau und Inhalt der FR3 zu verstehen und nutzbar zu machen.
Für was man die Infos dann nutzt ist eine andere Sache:
Ich könnte einen einfachen FR3-Interpreter in meine HBPrinter Klasse einbauen, aber mehr als normale Listen eventuell mit Gruppierung sollte man nicht erwarten.
Eventuell könnte ein anderer mit Infos von L&L und deren Dateien aber auch eine 1:1 Übersetzung machen

Hallo, Klaus.

Wäre es nicht einfacher, wenn jemand ein Konvertierungstool von FR3 auf L&L Reports erstellt.

Ich habe noch keine FR3-Datei gesehen (Beispiel?), aber ich nehme nicht an, dass das funktionieren würde. Dafür sind - neben den strukturellen, also das Format anbetreffenden - die inhaltlichen Unterschiede zu gravierend. L&L verwendet zwar auch ein XML-ähnliches Format, wobei es eigentlich zwei sehr ähnliche sind, nämlich einmal für statische Etikettenprojekte (.LBL) und einmal für dynamischere Listenprojekte (.LST). L&L unterscheidet im simplen Ansatz statische Inhalte (direkt platzierte Elemente, die unabhängig von der Datenquelle sind), Variablen (über das Projekt hinweg statische, aber von der Anwendung gelieferte Daten) und Felder (dynamische Daten, zeilenweise Änderung bei Tabellen). Wenn man mit Kreuz- und Verbundtabellen und weiteren Objekten arbeitet, wird es redlich kompliziert. Ich kenne den Ansatz von Frax nicht, aber L&L hat keine direkte Verbindung zur Datenquelle. Die Daten werden von der Anwendung publiziert.

Aber der Aufbau und das Design von Formularen mit L&L ist vergleichsweise simpel, kennt auch wiederverwendbare - modulare - Elemente und allgemeine Designschemata. Wer zehn, zwanzig Formulare zu überführen hat, ist besser bedient, wenn er das manuell macht. Schwierig(er) ist die Druck-/Export-/Vorschauroutine. Da baut man einige allgemeine Routinen und hängt sie in die entsprechenden Druckmechanismen, fertig. Der Druck von Listen für aktive Tabellen wäre eine solche Routine, mit ein paar zusätzlichen Parametern kann sie mehrdimensionale Arrays drucken. Und so weiter. Es hängt auch alles ein wenig davon ab, wie komplex die Reporte in der Applikation sind. Einfache Listen- und "Karteikarten"-Projekte stellen keine besondere Hürde dar. Man müsste, wenn es um mehr geht, vergleichen, was Frax kann und wie das in der Applikation umgesetzt wird. Das zu adaptieren wäre die eigentliche Aufgabe. Bei den Formularen sollte man auch die Chance nutzen, sie im Rahmen der Migration aufzuhübschen.

Das ist z.B. eine einfache Liste:

Code: Alles auswählen

<?xml version="1.0" encoding="utf-8"?>
<TfrxReport Version="3.22.19" DotMatrixReport="False" EngineOptions.DoublePass="True" EngineOptions.UseFileCache="True" IniFile="\Software\Fast Reports for XBase" PreviewOptions.Buttons="4095" PreviewOptions.OutlineWidth="180" PreviewOptions.Zoom="1" PrintOptions.Printer="Default" ReportOptions.CreateDate="37871.9953986921" ReportOptions.Description.Text="Demonstrates how to create simple list report." ReportOptions.Name="Simple list of customers report" ReportOptions.LastChange="38910.8126560648" ReportOptions.VersionBuild="1" ReportOptions.VersionMajor="12" ReportOptions.VersionMinor="13" ReportOptions.VersionRelease="1" ScriptLanguage="PascalScript" ScriptText.Text="begin&#13;&#10;&#13;&#10;end." PropData="044C656674021803546F70021808446174617365747301010C2700000020446174615365743D226F444D2E2220446174615365744E616D653D22437573746F6D657273220000095661726961626C65730100055374796C650100">
  <TfrxReportPage Name="Page1" PaperWidth="210" PaperHeight="297" PaperSize="9" LeftMargin="5" RightMargin="5" TopMargin="5" BottomMargin="5" Columns="1" ColumnWidth="210" ColumnPositions.Text="0" PrintOnPreviousPage="True" HGuides.Text="" VGuides.Text="">
    <TfrxReportTitle Name="Band1" Height="26.45671" Left="0" Top="18.89765" Width="755.906">
      <TfrxMemoView Name="Memo1" Align="baWidth" Left="0" Top="3.77953" Width="755.906" Height="22.67718" Color="8421376" Font.Charset="1" Font.Color="16777215" Font.Height="-16" Font.Name="Arial" Font.Style="1" HAlign="haCenter" ParentFont="False" VAlign="vaCenter" Text="Customers"/>
    </TfrxReportTitle>
    <TfrxPageHeader Name="Band2" Height="34.01577" Left="0" Top="68.03154" Width="755.906">
      <TfrxMemoView Name="Memo4" Left="204.09462" Top="7.55906000000002" Width="158.74026" Height="18.89765" Color="16777215" Font.Charset="1" Font.Color="128" Font.Height="-13" Font.Name="Arial" Font.Style="1" Frame.Typ="8" ParentFont="False" Text="Address"/>
      <TfrxMemoView Name="Memo5" Left="377.953" Top="7.55906000000002" Width="120.94496" Height="18.89765" Color="16777215" Font.Charset="1" Font.Color="128" Font.Height="-13" Font.Name="Arial" Font.Style="1" Frame.Typ="8" ParentFont="False" Text="Contact"/>
      <TfrxMemoView Name="Memo6" Left="514.01608" Top="7.55906000000002" Width="83.14966" Height="18.89765" Color="16777215" Font.Charset="1" Font.Color="128" Font.Height="-13" Font.Name="Arial" Font.Style="1" Frame.Typ="8" ParentFont="False" Text="Phone"/>
      <TfrxMemoView Name="Memo7" Left="612.28386" Top="7.55906000000002" Width="102.04731" Height="18.89765" Color="16777215" Font.Charset="1" Font.Color="128" Font.Height="-13" Font.Name="Arial" Font.Style="1" Frame.Typ="8" ParentFont="False" Text="Fax"/>
      <TfrxMemoView Name="Memo3" Left="7.55906" Top="7.55906000000002" Width="181.41744" Height="18.89765" Color="16777215" Font.Charset="1" Font.Color="128" Font.Height="-13" Font.Name="Arial" Font.Style="1" Frame.Typ="8" ParentFont="False" Text="Company"/>
    </TfrxPageHeader>
    <TfrxPageFooter Name="Band3" Height="26.45671" Left="0" Top="245.66945" Width="755.906">
      <TfrxMemoView Name="Memo2" Left="3.77953" Top="7.55905999999999" Width="710.55164" Height="15.11812" Color="16777215" Font.Charset="1" Font.Color="0" Font.Height="-11" Font.Name="Arial" Font.Style="0" Frame.Typ="4" Frame.Width="2" HAlign="haRight" ParentFont="False" Text="Page [Page] of [TotalPages]"/>
    </TfrxPageFooter>
    <TfrxMasterData Name="Band4" Height="22.67718" Left="0" Top="162.51979" Width="755.906" Columns="1" ColumnWidth="200" ColumnGap="20" DataSet="oDM." DataSetName="Customers" RowCount="0" Stretched="True">
      <TfrxMemoView Name="Memo13" Left="3.77953" Top="0" Width="714.33117" Height="18.89765" StretchMode="smActualHeight" DataSet="oDM." DataSetName="Customers" Highlight.Font.Charset="1" Highlight.Font.Color="-370606080" Highlight.Font.Height="-13" Highlight.Font.Name="Arial" Highlight.Font.Style="0" Highlight.Color="15790320" Highlight.Condition="<Line#> mod 2" WordWrap="False" Text=""/>
      <TfrxMemoView Name="Memo9" Left="204.09462" Top="0" Width="173.85838" Height="18.89765" StretchMode="smActualHeight" DataField="Address" DataSet="oDM." DataSetName="Customers" Text="[Customers."Address"]"/>
      <TfrxMemoView Name="Memo10" Left="377.953" Top="0" Width="136.06308" Height="18.89765" StretchMode="smActualHeight" DataSet="oDM." DataSetName="Customers" Text="[Customers."Contact"]"/>
      <TfrxMemoView Name="Memo11" Left="514.01608" Top="0" Width="98.26778" Height="18.89765" StretchMode="smActualHeight" DataSet="oDM." DataSetName="Customers" Text="[Customers."Phone"]"/>
      <TfrxMemoView Name="Memo12" Left="612.28386" Top="0" Width="102.04731" Height="18.89765" StretchMode="smActualHeight" DataSet="oDM." DataSetName="Customers" Text="[Customers."FAX"]"/>
      <TfrxMemoView Name="Memo8" Left="7.55906" Top="0" Width="196.53556" Height="18.89765" StretchMode="smActualHeight" TagStr="[Customers."Cust No"]" DataField="Company" DataSet="oDM." DataSetName="Customers" Text="[Customers."Company"]"/>
    </TfrxMasterData>
  </TfrxReportPage>
</TfrxReport>

das ist einfach, die anderen Beispiele sehen komplexer aus ...

Die Maße werden wohl meist in mm angegeben ( Left="0" Top="68.03154" ), aber das hier müssen pixel sein (Width="755.906"), den die Papierbreite wird mit 210 angegeben.

brandelh hat geschrieben:Ich habe die Testversion von FRAX erhalten und finde dort zwei Dateien:

FASTDEMO.CH
FASTDEMO.PRG

und den Hinweis, dass man FASTDEMO.OBJ dazu laden muss.
Ich frage mich gerade, wenn man diese beiden als Quellcode hat, wo genau kommen dann die Probleme her ?

FRSyst.dll

ist dies eine "angepasste" FastReport DLL, die intern auf das Xbase++ C-API zugreift ?

Wenn es eine normale C / Pascal DLL ist, müssten doch normale Aufrufe machbar sein, so wie QuickPDF ja auch aufgerufen wird.
Kennt sich damit jemand aus ?

Hallo Hubert,

die DLL enthält ausser des Fast-Report-Cpdes auch den Code von Sergej Spirin, der die Anbindung an Xbase++ ermöglicht, Diese Anbindung ist über C-API von Alaska realisiert. Das ist auch der Grund, warum es mit der 2.0 nicht funktioniert.

Noch ein kleiner Hinweis, der aber bestimmt nicht viel bringt.
Alaska plant den Reportgenerator von FoxPro in Xbase++ zu integrieren, weil dessen Code frei verfügbar und anwendbar ist. Dieser wird evtl. überarbeitet. Allerdings wird es wahrscheinlich nicht so schnell kommen.

Allerdings wird es wahrscheinlich nicht so schnell kommen.

das hatten wir doch schon 2012 oder vorher gehört ...

Irgendwann Mitte des vergangenen Jahrzehnts gab es auch mal die Ankündigung, L&L werde Bestandteil sein.

Stoff für einen Roman. Science Fiction.

Servus Hubert,

ich kenne Deine gute Druckerklasse, benutze sie ja selbst viel und auch Frax. Es wird nicht möglich sein, da eine Umsetzung von FR3 auf HBPrinter zu machen. Dazu ist Frax viel zu komplex: Mehrere Datenquellen, Aufruf von Xbase++-Funktionen im Report, Arrays, dbfs, Relationen, private-Variablen, Summen, Balkendiagramme, Tortendiagramme, Formeln, Formatierungen, If-Abfragen, Dialogfenster in versch. Programmierdialekten etc.

Da wärst du mindestens einige Monate voll damit beschäftigt, die Grundfunktionalitäten mit allen Varianten umzusetzen. Da wäre es sinnvoller und effektiver, auf Deiner HBPrinter-Klasse einen neuen Formulargenerator aufzusetzen.

Alaska hat uns jetzt etwas Zeit verschafft mit dem C-API-Schalter, in 6-x Monaten werden wir wohl mehr wissen, ob konkret von Alaska bezgl. Reportgenerator was kommt. Bis dahin kann man wohl noch ganz gut mit Frax arbeiten, irgendwann kommt halt dann der Schnitt zu einem neuen Reportgenerator-System. Notfalls muss man halt für komplexe nicht leicht umzusetzende FR3-Dateien eine 2. Kompatibilitäts-EXE aufrufen, die noch den Frax beinhaltet, bis auch der letzte Kunde das nicht mehr braucht, bzw. von uns auf das neue Report-System portiert werden konnte.

Sehe ich das falsch?

nein das sieht du richtig.

Für die einfachen Listen müsste ich einen internen Reportgenerator einbauen und es wird doch nie genug sein.
Einen GUI Formulargenerator wollen die meisten wohl auch, ich bin auch zu dem Schluß gekommen, dass das zu aufwändig ist.

brandelh hat geschrieben:Einen GUI Formulargenerator wollen die meisten wohl auch, ich bin auch zu dem Schluß gekommen, dass das zu aufwändig ist.

Den hatte ich vergessen zu erwähnen. Einige Kunden nutzen den ganz intensiv bei uns. Und der kann viel bei Frax...

Ein anderer Ansatz wäre, zu sehen, was nötig wäre um die FastReport DLL direkt anzusteuern.
FRAX nutzt ja intensiv die C-API von Xbase++ ... was sich wohl als Fehler herausgestellt hat, da Alaska die ändern musste.

Für die QuickPDF nutze ich den Zugriff über OT4XB (nötig wegen der Datentypen die Alaskas DLL-Funktionen nicht unterstützen.), die FR3 Dateien sehen mir nach FastReport aus.
Es sollte also möglich sein, die Xbase++ Teile in Xbase Quellcode nachzubauen und die Funktionan an FastReport weiterzureichen.
Ob das dann über seine DLL geht (die wohl auch FastReport integriert hat) oder man auch noch eine FastReport Lizenz bräuchte ist mir nicht klar.
Möglich wäre wohl auch, nur DAO Objekte zu nutzen oder mit den eingebauten Funktionen die Daten direkt zu übergeben (Beispiel mit dem Xbase++ Text).
In jedem Fall muss man sein Programm anpassen und in keinem Fall darf konkurierend auf die eigene DBF zugegriffen werden.

Ich persönlich würde aber auch nicht auf die Idee kommen einem Reportgenerator Datenverarbeitungsarbeiten aufzuhalsen.
Ich würde immer die Daten Änderungen vollziehen, die Druckergebnisse in Arrays/Objekten zwischenspeichern und dann als Report drucken lassen.
Im Hinblick auf eine mögliche SQL Umstellung ist es sowieso wichtig die Datensuche von Anzeige bzw. Druck zu trennen.

Ich habe ja mit beidem nichts am Hut, daher weder die einschlägigen Kenntnisse noch die Notwendigkeit mich da weiter reinzuhängen

Inoffizielles deutsches Xbase-Forum

Ersatz für Frax

Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax

Re: Ersatz für Frax