Frax

Hier können die Unterschiede, Fehler und Probleme zwischen den Versionen bzw. bei der Migration besprochen werden

Moderator: Moderatoren

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1507
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Frax

Beitrag von Werner_Bayern » Do, 16. Okt 2014 23:07

brandelh hat geschrieben:eventuell ist es leichter komplett auf L&L umzustellen, das hat eine breite User Basis.
Und ein ganz anderes Konzept! Stichpunkt Datenzugriff etc..
Und alle Reporte müssten komplett neu erstellt werden...
es grüßt euch

Werner

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13024
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Frax

Beitrag von Jan » Fr, 17. Okt 2014 6:27

Ich möchte nicht schwarzmahlen. Aber wenn bei Frax alle Stricke reißen - auf dem Forentreffen im April 2015 wird Jochen Bartlau dabei sein. Der arbeitet für Combit, deren Produkt ist List&Label.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11350
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Frax

Beitrag von AUGE_OHR » Fr, 17. Okt 2014 18:53

hi,

irgendwie habe ich das Gefühl das viele glauben das "wir" einen Fehler machen und nicht Alaska mit seiner Änderung.

könnte jemand bitte mal den Abschnitt aus dem neuen Help File ins Forum stellen, Danke
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Sa, 18. Okt 2014 10:58

Welchen Ausschnitt ?

Die Änderungen in der C-API stehen - soweit ich weis - nirgends.
Das wurde nur in der NEWS group erwähnt, wegen FileTime64() etc.

Welches Problem FRAX hat weiß ich nicht, QuickPDF scheint nicht betroffen.

Ein FEHLER liegt aber eigentlich gar nicht vor, da Alaska NIE garantiert hat, dass Zusatztools weiter funktionieren.
Das macht auch KEIN Hersteller egal wo du nachsiehst.
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11350
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Frax

Beitrag von AUGE_OHR » Mo, 20. Okt 2014 1:21

brandelh hat geschrieben:Welchen Ausschnitt ?

Die Änderungen in der C-API stehen - soweit ich weis - nirgends.
Das wurde nur in der NEWS group erwähnt, wegen FileTime64() etc.
es wurde doch geschrieben
Andreas Herdt hat geschrieben:Mit Xbase++ 2.0 haben wir das interne Typen Management überarbeitet,
das bedingt ein neues Bauen aller Bibliotheken die unter Verwendung
der C-API in C/C++ gebaut wurden.

Es ist dann auch die geänderte Dokumentation der C-API zu beachten, die
beschreibt, wie auf Xbase++ Typen hin zu prüfen. ist.
die meine ich wenn man raus finden will was geändert wurde
brandelh hat geschrieben:Welches Problem FRAX hat weiß ich nicht, QuickPDF scheint nicht betroffen.
dazu die Frage ob es immer 64bit OS() ist oder auch mit 32bit OS() bei FRAX passiert ?
brandelh hat geschrieben:Ein FEHLER liegt aber eigentlich gar nicht vor, da Alaska NIE garantiert hat, dass Zusatztools weiter funktionieren.
Das macht auch KEIN Hersteller egal wo du nachsiehst.
es gibt ja eine Windows API ...

wir wissen ja immer noch nicht ob "wir" einen Fehler gemacht haben, es tatsächlich zwischen der Beta5 und RC1 die neue C-API eingeführt wurde ...
oder Alaska einfach Mist gebaut hat.
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Mo, 20. Okt 2014 8:28

AUGE_OHR hat geschrieben:
brandelh hat geschrieben: Das wurde nur in der NEWS group erwähnt, wegen FileTime64() etc.
es wurde doch geschrieben
Andreas Herdt hat geschrieben:Mit Xbase++ 2.0 haben wir das interne Typen Management überarbeitet,
das bedingt ein neues Bauen aller Bibliotheken die unter Verwendung
der C-API in C/C++ gebaut wurden.

Es ist dann auch die geänderte Dokumentation der C-API zu beachten, die
beschreibt, wie auf Xbase++ Typen hin zu prüfen. ist.
die meine ich wenn man raus finden will was geändert wurde
Dein Zitat bezieht sich doch aber auf die Newsgroup oder eine private eMail oder ?

Ich habe die Liste der Dokumentationsänderungen in meinen Editor geladen (so viele Zeilen durchsuche ich nicht gerne mit den Augen ;-) )
Suche nach api (Groß/Kleinschreibung egal) ... 0 Treffer !

Möglich, dass einige Seiten dort geändert wurden, ich lese mir die ja nie durch, aber markiert ist nichts (was ich gefunden hätte).
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11350
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Frax

Beitrag von AUGE_OHR » Mo, 20. Okt 2014 16:30

brandelh hat geschrieben:Dein Zitat bezieht sich doch aber auf die Newsgroup oder eine private eMail oder ?
Newsgroup
brandelh hat geschrieben:Ich habe die Liste der Dokumentationsänderungen in meinen Editor geladen (so viele Zeilen durchsuche ich nicht gerne mit den Augen ;-) )
Suche nach api (Groß/Kleinschreibung egal) ... 0 Treffer !

Möglich, dass einige Seiten dort geändert wurden, ich lese mir die ja nie durch, aber markiert ist nichts (was ich gefunden hätte).
genau das ist ja das Problem.
Alaska redet über eine geänderte Dokumentation und gibt uns die nicht ... woher sollen wir also wissen was (angeblich) geändert wurde ?
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Di, 21. Okt 2014 8:30

=D>
Gruß
Hubert

Benutzeravatar
Schubi
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 126
Registriert: Mi, 05. Okt 2005 15:10
Wohnort: Wiesloch

Re: Frax

Beitrag von Schubi » Mi, 22. Okt 2014 12:02

Ich habe bei Alaska nachgefragt, ob ein Kompatibiltätsschalter für alte C-API Lösungen denkbar wäre. Dies scheint jedoch nicht möglich.
Hier ein Auszug aus dem Schreiben von Alaska:

Für Xbase++ wurde das interne Typen System modifiziert,
dies unter anderem auch um für neue Datentypen vorbereitet
zu sein. Hierfür werden selbstverständlich auch die C-API
Header Dateien auf den neuesten Stand gebracht.

Existierender C-API Code muss deshalb mit den neuen Header
Dateien neu gebaut werden. Andere Modifikationen sind nicht
notwendig.

Es ist technisch nicht möglich bei einer derartigen binären
Inkompatibilität rückwärtskompatibel zu sein. Das geht auch
mit einem Schalter nicht.

Alter Code wird mit Xbase++ 2.0 nicht gebrochen, allerdings
bezieht sich diese Aussage selbstverständlich nur auf Xbase++
PRG code.

Bitte kompilieren Sie Ihre C Dateien erneut mit den C-API Headern
von Xbase++ 2.0. Beachten Sie hierbei die Makros zur Prüfung
von Xbase++ Typen. Unter der C-API Funktion _partype(). Wenn
Sie diese Makros in Ihren vorhandenen Quellen benutzt haben,
dann sind keine weiteren Masnamen notwendig, wir haben
Sorge dafür getragen, dass die Makros kompatibel geblieben
sind.


Wir müssen also für den Frax eine andere Lösung finden.
Andreas tu etwas! :)
Grüße Steffen

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Mi, 22. Okt 2014 12:44

Werner_Bayern hat geschrieben:Und jetzt :?: :?: :?:
Muss FRAX die DBF selbst lesen ?
Wenn Frax die Möglichkeit bietet Strings oder Arrays mit Daten zu übergeben, statt direkt auf die DBF zuzugreifen,
sollte es am einfachsten sein das so umzustellen. Falls es Objektorientiert ist, könnte man ja eine Klasse bauen,
die dem alten Code die Felder abnimmt und in Arrays umsetzt und FRAX aufruft.
Oder man macht die Anpassung über #Translate / #Command ...

allerdings kenne ich mich mit Frax nicht aus, daher nur diese allgemeinen Überlegungen ... :wink:
Gruß
Hubert

Benutzeravatar
Schubi
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 126
Registriert: Mi, 05. Okt 2005 15:10
Wohnort: Wiesloch

Re: Frax

Beitrag von Schubi » Mi, 22. Okt 2014 14:35

Kommando zurück!
Alles wieder auf Anfang!
Alaska hat mir gerade geschrieben, dass sie sich bezüglich Fastreport noch einmal bei mir melden wollen!
Also seid fröhlich in Hoffnung!
Grüße Steffen

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1507
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Frax

Beitrag von Werner_Bayern » Do, 23. Okt 2014 0:08

Servus Hubert,

ja, Arrays gehen. Aber was funktioniert noch alles nicht? Keine Ahnung. Ob das der Aufwand wert ist? Wenn von DBF-Zugriff auf Arrays umgestellt wird, ist auch einiges an Codierungsaufwand nötig, auch auf Kundenseite.

M. M. n. die bessere Lösung: Irgendjemand führt Frax fort! Wenn es nur ums Neukompilieren geht, dann mach ich das zur Not, kann ja nicht so schwierig sein. Blöd nur, hab erst vor 1 Monat mein Delphi verkauft, stand jahrelang im Regal, unbenutzt.

Oder, so wie es aussieht und was auch Sinn machen würde, vereinnahmt Alaska sich das?
es grüßt euch

Werner

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Do, 23. Okt 2014 0:26

Werner_Bayern hat geschrieben:Oder, so wie es aussieht und was auch Sinn machen würde, vereinnahmt Alaska sich das?
wie kommst du auf die Idee ?

Soweit ich weiß ist Xbase++ in C/C++ und Xbase++ selbst geschrieben, wieso sollten die sich FRAX einkaufen und mit Delphi anfangen ?

Was Steffen auf einer der Vorträge mal erwähnt hat ist, dass wir einen Reportgenerator von Foxpro erhalten sollen, der als Quellcode geliefert würde ...
gesehen habe ich noch nichts, aber das muss nichts heißen ;-)
Gruß
Hubert

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1507
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Frax

Beitrag von Werner_Bayern » Do, 23. Okt 2014 0:32

brandelh hat geschrieben:wie kommst du auf die Idee ?
Schubi hat geschrieben:Alaska hat mir gerade geschrieben, dass sie sich bezüglich Fastreport noch einmal bei mir melden wollen!
es grüßt euch

Werner

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11350
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Frax

Beitrag von AUGE_OHR » Do, 23. Okt 2014 1:35

Werner_Bayern hat geschrieben:
Schubi hat geschrieben:Alaska hat mir gerade geschrieben, dass sie sich bezüglich Fastreport noch einmal bei mir melden wollen!
Fastreport ist aber nicht FRAX ...

bezüglich L&L : hast da schon jemand Inkompatibilität festgestellt ?
gruss by OHR
Jimmy

Benutzeravatar
satmax
1000 working lines a day
1000 working lines a day
Beiträge: 791
Registriert: Do, 02. Dez 2010 19:34
Wohnort: Biberbach in Österreich
Kontaktdaten:

Re: Frax

Beitrag von satmax » Do, 23. Okt 2014 1:59

LL läuft einwandfrei. Ist ja auch eine DLL Schnittstelle.
Gruß
Markus

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11350
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Frax

Beitrag von AUGE_OHR » Do, 23. Okt 2014 3:15

satmax hat geschrieben:LL läuft einwandfrei. Ist ja auch eine DLL Schnittstelle.
die Zugriffe auf Windows DLL, wie FileTime(), benötigen ja einen "Wrapper" damit die mit Xbase++ funktionieren und "da" ist das Problem.

also auch wenn man den Source von Frax hätte und jemanden der sich da rein arbeiten würde dann wäre das Problem noch nicht behoben ... wenn man nicht weiss wonach man suchen soll.
Bitte kompilieren Sie Ihre C Dateien erneut mit den C-API Headern
von Xbase++ 2.0. Beachten Sie hierbei die Makros zur Prüfung
von Xbase++ Typen. Unter der C-API Funktion _partype(). Wenn
Sie diese Makros in Ihren vorhandenen Quellen benutzt haben,
dann sind keine weiteren Masnamen notwendig, wir haben
Sorge dafür getragen, dass die Makros kompatibel geblieben
sind.
also es wäre nett wenn jemand mal die "neue" c:\ALASKA\XPPW32\Include\xppdef.h mit der alten vergleichen würde ( oder es hier uploadet )
gruss by OHR
Jimmy

Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 13024
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Kontaktdaten:

Re: Frax

Beitrag von Jan » Do, 23. Okt 2014 5:07

Jimmy,

warum willst Du eigentlich ständig, das jemand mal irgendwelche Sachen von 2.0 hier hochlädt? Du hast die Dateien doch selber und kannst Dir die auch so ansehen.

Und einfach mal eben Dateien von Alaska komplett hier veröffentlichen dürfte vermutlich auch nicht ganz legal sein.

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11350
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Frax

Beitrag von AUGE_OHR » Do, 23. Okt 2014 7:49

Jan hat geschrieben:warum willst Du eigentlich ständig, das jemand mal irgendwelche Sachen von 2.0 hier hochlädt? Du hast die Dateien doch selber und kannst Dir die auch so ansehen.
NEIN weil ich kein Geld für die V2.x Release ausgebe so wie die jetzt ist und unter den Bedingungen.

Im übrigen geht es um die Information, wenn sich was geändert haben sollte, "was" sich nun (angeblich) geändert hat.

ich habe die v.2.x Beta5 (519) und da sind xppcon.h , xppdef.h und xpppar.h EXAKT gleich zur v1.9.355 Version !
wenn Frax also mit der Beta5 Version schon nicht mehr läuft dann kann das NICHT an einer geänderten C-API Schnittstelle liegen.
wenn sich das im v2.x Release geändert hat wäre es nett wenn das jemand posten könnte.

p.s. irgendwie kommt mir die Geschichte bekannt vor ... bei JazzAge wurde das auch erzählt und die XOANON Lib wurde ja auch eingestellt nachdem kurzfristige Änderungen beide unbrauchbar gemacht haben.
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Do, 23. Okt 2014 8:38

nachmal, FRAX ist ein privates Produkt. OHNE die Erlaubnis und den Quellcode kann man da GAR NIX machen außer seine eigenen Programme anzupassen :!:
AUGE_OHR hat geschrieben:ich habe die v.2.x Beta5 (519) und da sind xppcon.h , xppdef.h und xpppar.h EXAKT gleich zur v1.9.355 Version !
die Dateien zu vergleichen ist nicht das Problem ;-)

Code: Alles auswählen

 Unterschiede von ... <! = 1.90.355 !> = 2.00.556  ...-ermittelt mit WinDiff
xppcon.h
 <! //     Alaska Software, (c) 1997-2009. All rights reserved.         
 !> //     Alaska Software, (c) 1997-2014. All rights reserved. 

xppdef.h
 <! //     Alaska Software, (c) 1997-2009. All rights reserved.         
 !> //     Alaska Software, (c) 1997-2014. All rights reserved.      

xpppar.h
 <! //     Alaska Software, (c) 1997-2009. All rights reserved.         
 !> //     Alaska Software, (c) 1997-2014. All rights reserved. 
Ich kenne mit mit C/C++ nicht wirklich aus, aber diese Unterschiede sollten nicht ins Gewicht fallen ;-)
Gruß
Hubert

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Do, 23. Okt 2014 9:04

ich konnte es mir nicht verkneifen ... NEWS-GROUP:

Code: Alles auswählen

Am 08.10.2014 11:10, schrieb Andreas Herdt:
> With Xbase++ 2.0 we have changed the internal type defines, a rebuild
> of libraries is required that are implemented in C/C++ using the C-API
> and the corresponding C/C++ header files.
>
> The updated C-API documentation must be taken into consideration on
> how Xbase++ types are to be identified from C/C++.

1. Question, where is the C-API with changes, I can't find changes in the Dokumentation ... but I can't use  C/C++ so this don't help realy .

2. "C/C++ header files." do this mean *.H in the include directory ?
I have checked the *.H files from 1.90.355 and 2.00.556

Here is a list of changed text in this *.H files:

<! = 1.90.355 !> = 2.00.556  ... searched with WinDiff

xppcon.h
 <! //     Alaska Software, (c) 1997-2009. All rights reserved.
 !> //     Alaska Software, (c) 1997-2014. All rights reserved.

xppdef.h
 <! //     Alaska Software, (c) 1997-2009. All rights reserved.
 !> //     Alaska Software, (c) 1997-2014. All rights reserved.

xpppar.h
 <! //     Alaska Software, (c) 1997-2009. All rights reserved.
 !> //     Alaska Software, (c) 1997-2014. All rights reserved.

and the source files from the CAPI folder in the samples are more than 10 Years old.

very strange to me ...
Gruß
Hubert

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Do, 23. Okt 2014 9:24

1.9 - ULONG _partype(XppParamList pList, ULONG ulIndex);
2.0 - ULONG _partype(XppParamList pList, ULONG ulIndex);

1.9 - Indexliste

Code: Alles auswählen

Mögliche Rückgabewerte von _partype() 
  Makro-Name     Dezimalwert  hex. Wert  Bedeutung                         

  XPP_UNDEF      1            0x0001     Typ: NIL                          
  XPP_CHARACTER  2            0x0002     Typ: Zeichenkette                 
  XPP_NUMERIC    4            0x0004     Typ: Numerisch                    
  XPP_LOGICAL    8            0x0008     Typ: Logisch                      
  XPP_DATE       16           0x0010     Typ: Datum                        
  XPP_ARRAY      32           0x0020     Typ: Array                        
  XPP_BLOCK      64           0x0040     Typ: Codeblock                    

  XPP_OBJECT     128          0x0080     Typ: Objekt                       
  XPP_REFERENCE  256          0x0100     Info: Referenz-Parameter          
  XPP_MEMO       512          0x0200     Typ: Memo-Zeichenkette            
  XPP_DOUBLE     1024         0x0400     Info: Numerischer Wert besitzt entweder Dezimalstellen oder ist zu groß für LONG 
2.0

Code: Alles auswählen

Macro           Type                        Meaning 

XPP_IS_UNDEF()  XPP_UNDEF                   NIL 
XPP_IS_CHAR()   XPP_CHARACTER or XPP_MEMO   Character string
XPP_IS_MEMO()   XPP_MEMO                    Memo character string 
XPP_IS_NUM()    XPP_NUMERIC or XPP_DOUBLE   Numeric
XPP_IS_FLOAT()  XPP_DOUBLE                  Floating point 
XPP_IS_LOGIC()  XPP_LOGICAL                 Logical 
XPP_IS_DATE()   XPP_DATE                    Date 
XPP_IS_ARRAY()  XPP_ARRAY                   Array 
XPP_IS_BLOCK()  XPP_BLOCK                   Code block 
XPP_IS_OBJECT() XPP_OBJECT                  Object 
XPP_IS_REFPAR()                             Parameter was passed by reference 
Ich sehe da keine Änderungen, außer der KLARSTELLUNG:
It should be noted that for some types more then one bit is masked in the return value. Furthermore, the numeric value representing a type may change in future Xbase++ versions. Because of these reasons the return value should be tested with one of the macros defined in the header file xpppar.h. The following table lists the macros and the types for which the macro evaluates to true:
Gruß
Hubert

Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1507
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern

Re: Frax

Beitrag von Werner_Bayern » Do, 23. Okt 2014 12:07

AUGE_OHR hat geschrieben:Fastreport ist aber nicht FRAX ...
Frax ist doch m. W. n. eine Anpassung von Fastreport an Xbase++ (und weitere Programmiersprachen).
es grüßt euch

Werner

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14504
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Frax

Beitrag von brandelh » Do, 23. Okt 2014 13:08

Gruß
Hubert

Benutzeravatar
andreas
Foren-Moderator
Foren-Moderator
Beiträge: 1727
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Kontaktdaten:

Re: Frax

Beitrag von andreas » Do, 23. Okt 2014 13:17

Hallo an Alle,

FRAX ist tatsächlich FastReport für Alaska Xbase++. Wer meinen Vortrag bei der letzten DevCon besucht hat, weiß es auch. Die Quellen von FastReport werden durch den Partner genommen, in diesem Fall Sergej Spirin, und mit eigener Schnittstelle zu der Sprache (Xbase++) in eine DLL kompilert. Also die Schnittstelle zu Xbase++ kommt von Sergej und es ist FastReport!

Ich vermute, dass es nicht nur an der C-API liegt, sondern auch an den DBEs, weil ein direkter Zugriff darauf stattfindet. Sergej hat schon mal nach einem von mir gemeldeten Fehler in Bezug auf die neuen Timestamp-Felder in FOXDBE gesucht und Unterschiede bei den Formaten gefunden gehabt. Sergej musste FRAX anpassen, um die Feldwwerte richtig auslesen zu können. Also liegt die Vermutung, dass an der DBE etwas verändert wurde und der Zugriff auf die Memo-Felder nicht mehr möglich ist. Diese Stelle müsste in den Quellen von Sergej in Zusammenarbeit mit Alaska angepasst und FRAX neu kompiliert werden. Aus diesem Grund habe ich auch gefragt, wer hier sich mit Delphi (in Version 3, wenn ich mich nicht täusche) auskennt. Ich könnte mir vorstellen, dass wir evtl. einen Zugriff auf den Sergejs PC (evtl. unter Beobachtung) zur Anpassung und Kompilierung des Quellcodes aushandeln könnten. Das wäre die günstigste Variante! So wie ich es gelesen habe, haben wir schon Werner als einen Kandidaten dafür.
Gruß,

Andreas
VIP der XUG Osnabrück
Beisitzer des Deutschsprachige Xbase-Entwickler e. V.

Antworten