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