Hallo Herr Martl,
der Grund für die Probleme mit Frax ist wie folgt:
1.) Die CAPI Funktionen _conType(), _conTypeA(), _partype()
und _paratype() liefern in der 2.0 andere numerische Werte zurück
als in 1.9. Um genau zu sein wurde das Typen-System der Xbase++
Runtime um “SubTyping” erweitert. Dies ist notwendig für die
Unicode Unterstützung in 3.0.
Eigentlich ist diese Umstellung kein Problem da wir die Macros
in den “C/C++ Headern” entsprechend angepasst haben, da Frax aber
in Delphi implementiert ist muss der Delphi Code angepasst und
übersetzt werden.
1.1) Wir haben durch Disassemblierung sowie “debugging” der
FRSyst.dll die in Position 1 getroffene Aussage bewiesen.
1.2) Korrekt, der Numeric type hat den Integer als SubType,
der character type hat den Memo als SubType. Dies SubTypen werden
nicht mehr erkannt – ergo gehen Memo und Integer Werte nicht
mehr.
2.) Der Autor ist unseres Wissens nach im März 2012
verstorben.
Nun aber das wichtigste.
1.) Wir arbeiten an diesem Thema bereits seit Sept. mit
Andreas Engler zusammen.
2.) Wie bereits bekannt war ja die ursprüngliche Idee das wir
das Frax System an die 2.0 anpassen. Leider sind die Verhandlungen
mit der Rechtsnachfolgerin gescheitert.
3.) Auf den Frankfurter Xbase++ Tracks 2014 habe ich mit
Andreas am Samstag dann das Frax System analysiert um alternative
Wege zu formulieren. Dies mit folgendem Ergebnis:
3a.) Kurzfristige Lösung: Alaska Software erlaubt das das
Verhalten der CAPI durch einen Config-Schalter (resource file)
wieder 1.9 kompatibel gemacht werden kann. Das löst zwar das
Problem mit Frax führt aber dazu das kein anderes Add-On welches
die CAPI benutzt verwendet werden kann oder aber nur die 1.9
kompatible Version.
3b.) Wir prüfen ob die FR3 Dateien welche Frax erzeugt sich in
das Report-Format der Version 3.0 konvertieren lässt. Damit können
die Report-Definition gerettet werden. Der Code mit dem Frax
angesteuert wird muss aber durch Xbase++ 3.0 code ersetzt
werden.
Sowohl 3a als auch 3b sind zur Zeit in der Prüfung
(Machbarkeits-Experimente). Eine offizielle Aussage wird es hierzu
in ein paar Wochen auf jeden Fall noch dieses Jahr geben.
Im übrigen ist die Unterstützung durch die Betroffenen sehr
mäßig, du bist der zweite der sich mit diesem Thema an Alaska
Software wendet – die anderen scheinen irgendwie nur zu
lästern.
Auch die Bitte von Andreas Engler, beispielhafte Reports
einzureichen war nicht von Erfolg gekrönt. Nur ein Frax Nutzer hat
hier Reports an Andreas weitergereicht.
Mit besten Grüßen
Steffen F. Pirsig
Alaska Software Inc.
"Werner Martl" schrieb im Newsbeitrag
news:7dfb8da6$2eb7f4e$1d61a3@news.alaska-software.com...
Servus Alaska,
woran kann es liegen, dass mit der 2.0 Frax nur noch teilweise
funktioniert, was hat sich da geändert?
Wenn man aus Frax heraus auf Xbase++ - numerische
(Integer)-Variablen zugreifen will (GetXppVar()), ist die Rückgabe
immer 0. Ebenso bei Arrays. Definiert man in Xbase++ die
Zahlenwerte als Gleitkommazahl, dann funktioniert es.
Desweiteren funktioniert bei Reports der Zugriff auf
DBF-Memo-Felder nicht mehr, der Report bricht ab und hinterlässt
teilweise einen undefinierten Zustand in der dbe.
Zugriffe erfolgen über die FRSyst.dll, die mittels Delphi
erstellt wurde. Die Klasse für die Zugriffe auf FastReport wird im
Xbase++ - Quellcode mitgeliefert, dort erfolgen die Aufrufe auf
FRSyst.dll mittels DllExecuteCall:
::_ShowPreparedReport := DllPrepareCall(::frSystHandle,
DLL_STDCALL, "ShowPreparedReport")
DllExecuteCall(::_ShowPreparedReport)
Bekannterweise ist ja leider der Autor von Frax letztes Jahr
verstorben und daher gibt es aktuell keinen Support mehr.
Danke,
Werner