Seite 2 von 6
Re: Frax
Verfasst: Do, 16. Okt 2014 23:07
von Werner_Bayern
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...
Re: Frax
Verfasst: Fr, 17. Okt 2014 6:27
von Jan
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
Re: Frax
Verfasst: Fr, 17. Okt 2014 18:53
von AUGE_OHR
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
Re: Frax
Verfasst: Sa, 18. Okt 2014 10:58
von brandelh
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.
Re: Frax
Verfasst: Mo, 20. Okt 2014 1:21
von AUGE_OHR
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.
Re: Frax
Verfasst: Mo, 20. Okt 2014 8:28
von brandelh
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).
Re: Frax
Verfasst: Mo, 20. Okt 2014 16:30
von AUGE_OHR
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 ?
Re: Frax
Verfasst: Di, 21. Okt 2014 8:30
von brandelh
=D>
Re: Frax
Verfasst: Mi, 22. Okt 2014 12:02
von Schubi
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!
Re: Frax
Verfasst: Mi, 22. Okt 2014 12:44
von brandelh
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 ...
Re: Frax
Verfasst: Mi, 22. Okt 2014 14:35
von Schubi
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!
Re: Frax
Verfasst: Do, 23. Okt 2014 0:08
von Werner_Bayern
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?
Re: Frax
Verfasst: Do, 23. Okt 2014 0:26
von brandelh
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
Re: Frax
Verfasst: Do, 23. Okt 2014 0:32
von Werner_Bayern
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!
Re: Frax
Verfasst: Do, 23. Okt 2014 1:35
von AUGE_OHR
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 ?
Re: Frax
Verfasst: Do, 23. Okt 2014 1:59
von satmax
LL läuft einwandfrei. Ist ja auch eine DLL Schnittstelle.
Re: Frax
Verfasst: Do, 23. Okt 2014 3:15
von AUGE_OHR
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 )
Re: Frax
Verfasst: Do, 23. Okt 2014 5:07
von Jan
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
Re: Frax
Verfasst: Do, 23. Okt 2014 7:49
von AUGE_OHR
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.
Re: Frax
Verfasst: Do, 23. Okt 2014 8:38
von brandelh
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
Re: Frax
Verfasst: Do, 23. Okt 2014 9:04
von brandelh
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 ...
Re: Frax
Verfasst: Do, 23. Okt 2014 9:24
von brandelh
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:
Re: Frax
Verfasst: Do, 23. Okt 2014 12:07
von Werner_Bayern
AUGE_OHR hat geschrieben:Fastreport ist aber nicht FRAX ...
Frax ist doch m. W. n. eine Anpassung von Fastreport an Xbase++ (und weitere Programmiersprachen).
Re: Frax
Verfasst: Do, 23. Okt 2014 13:08
von brandelh
Re: Frax
Verfasst: Do, 23. Okt 2014 13:17
von andreas
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.