Ersatz für Frax
Moderator: Moderatoren
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2471
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 103 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Ersatz für Frax
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.
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.
Zuletzt geändert von brandelh am Di, 17. Mär 2015 10:23, insgesamt 2-mal geändert.
Grund: BRANDELH: Einbau einer Abfrage wie gewünscht.
Grund: BRANDELH: Einbau einer Abfrage wie gewünscht.
Gruß
Klaus
Klaus
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für Frax
nö, die sind eindeutig bekannt !Koverhage hat geschrieben:und was der neue Kompatibilitätsschalter für negative Auswirkungen hat ist wohl noch relativ unbekannt.
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 ...
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für Frax
gibt es eigentlich eine Dokumentation, wie FRAX die Reports speichert ?
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für Frax
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.
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.
Gruß
Hubert
Hubert
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für Frax
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 ?
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 ?
Gruß
Hubert
Hubert
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2471
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 103 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Ersatz für Frax
Kannst Du aus der Zielrichtung eine Umfrage machen ?
Was meinst Du damit ?Falls jemand die "Designer" insbesondere für seine Kunden benötigt, ist 1. zu wenig ... hätte jemand Interesse die FR3 zu zerlegen ?
Gruß
Klaus
Klaus
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für Frax
gerne, obwohl du das auch gekonnt hättest, da es ja DEIN Thread istKoverhage hat geschrieben:Kannst Du aus der Zielrichtung eine Umfrage machen ?
PS: nur im ersten Beitrag eines Threads kann man eine Umfrage starten, auch nachträglich durch ändern.
Davon den Aufbau und Inhalt der FR3 zu verstehen und nutzbar zu machen.Koverhage hat geschrieben:Was meinst Du damit ?Falls jemand die "Designer" insbesondere für seine Kunden benötigt, ist 1. zu wenig ... hätte jemand Interesse die FR3 zu zerlegen ?
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
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9388
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 362 Mal
- Kontaktdaten:
Re: Ersatz für Frax
Hallo, Klaus.
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.
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.Wäre es nicht einfacher, wenn jemand ein Konvertierungstool von FR3 auf L&L Reports erstellt.
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.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für Frax
Das ist z.B. eine einfache Liste:
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.
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 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>
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.
Gruß
Hubert
Hubert
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Re: Ersatz für Frax
Hallo Hubert,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 ?
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.
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Re: Ersatz für Frax
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.
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.
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9388
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 362 Mal
- Kontaktdaten:
Re: Ersatz für Frax
Irgendwann Mitte des vergangenen Jahrzehnts gab es auch mal die Ankündigung, L&L werde Bestandteil sein.
Stoff für einen Roman. Science Fiction.
Stoff für einen Roman. Science Fiction.
Herzlich,
Tom
Tom
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Ersatz für Frax
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?
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?
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für Frax
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.
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.
Gruß
Hubert
Hubert
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2126
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Ersatz für Frax
Den hatte ich vergessen zu erwähnen. Einige Kunden nutzen den ganz intensiv bei uns. Und der kann viel bei Frax...brandelh hat geschrieben:Einen GUI Formulargenerator wollen die meisten wohl auch, ich bin auch zu dem Schluß gekommen, dass das zu aufwändig ist.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- brandelh
- Foren-Moderator
- Beiträge: 15701
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 69 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Ersatz für 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
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
Gruß
Hubert
Hubert