Inoffizielles deutsches Xbase-Forum

AUGE_OHR hat geschrieben:hier im Forum wird zwar heftig diskutiert aber davon bekommt Alaska nichts mit und keinen "Druck".
warum schreibt keiner von euch was im Alaska News Forum ... traut ihr euch nicht ?

Andreas ist doch diesbezüglich eh in Kontakt mit Steffen, hat er doch geschrieben.

andreas hat geschrieben:nein, leider habe ich noch keine fr3-Dateien erhalten. Ich wollte ein Paar von meinen auch noch dazu packen.

Hab ich Dir soeben geschickt. Danke für Deine Bemühungen!

Werner_Bayern hat geschrieben:

AUGE_OHR hat geschrieben:hier im Forum wird zwar heftig diskutiert aber davon bekommt Alaska nichts mit und keinen "Druck".
warum schreibt keiner von euch was im Alaska News Forum ... traut ihr euch nicht ?

Andreas ist doch diesbezüglich eh in Kontakt mit Steffen, hat er doch geschrieben.

Es ist doch ein Problem mit Xbase++ v2.x und "das" sollte ein Frax User im Alaska Forum posten um auch andere Frax User darauf aufmerksam zu machen !
Es sind doch wohl nur 1/10 Deutsche Frax User und nicht alle sind hier im Forum.

ich wünsche Andreas viel Erfolg ... aber eine einzelne Person kann meisten nicht so viel erreichen wie eine "Menge" die zusammenhalten.

Jimmy,

ich persönlich vertraue Andreas da. Sollte er keinen Erfolg haben, ist das sicher keine schlechte Idee.

Was ich aber sinnvoll fände: Du hast doch hier schon Vorarbeit geleistet und offensichtlich herausgefunden, dass die Aussage von Alaska mit den Header-Dateien nicht stimmt. Schreib doch unabhängig von dem Frax-Problem Deine Erkenntnisse ins Alaska-Forum. Dann funken wir Andreas nicht dazwischen und das Problem wird bei Alaska von einer 2. Seite aus angesprochen.

Was hältst Du davon?

Werner_Bayern hat geschrieben:Schreib doch unabhängig von dem Frax-Problem Deine Erkenntnisse ins Alaska-Forum.

hast du einen Beitrag in den letzten Jahr von mir im Alaska Forum gesehen ...
Hubert hat das Thema ja als Antwort im Alaska Forum veröffentlicht aber es kam ja KEINE Antwort !

p.s. ich habe ja das "Filetime" Problem selbst behoben und die Lösung hier im Forum veröffentlicht.

Wobei ich wirklich nicht weiß, ob die Tatsache dass die Headerdateien gleich sind wirklich beweißt, dass die C-API nicht geändert wurde
Das würde ich nicht behaupten, denn ich habe keine Ahnung von der C-API !

ok, war mir nicht bewusst. Aber ich kann doch nichts an Alaska schreiben, was ich nicht selber überprüft / festgestellt habe...

Was Jimmy einfach nicht wahrhaben will ist, dass Alaska nicht für FRAX verantwortlich ist.
In einem der Beiträge zur OT4XB wurde deutlich geschrieben, dass der Hersteller (hier Pablo) die neue C-API beachten und dann neu kompilieren muss.
Das Versprechen keinen Code zu brechen (das ja so auch nicht immer eingehalten wurde ) gilt nur für PRG Code, nicht für die C-API oder andere Objektdateien von Fremdherstellern.

Im Übrigen, egal was alle versprechen, wer es eilig hat, sollte sich sichere Lösungen überlegen die er selbst beeinflussen kann.
Zu warten, dass irgendjemand seine Probleme wieder löst ist blauäugig

brandelh hat geschrieben:Wobei ich wirklich nicht weiß, ob die Tatsache dass die Headerdateien gleich sind wirklich beweißt, dass die C-API nicht geändert wurde

es geht ja "nur" um die Schnittstelle die uns zur Verfügung steht ... wenn Alaska andere hat ...

bei Frax ist ja wohl (auch) ein Problem mit der DBE (Memo) und da haben wir ja überhaupt keine API Beschreibung.

brandelh hat geschrieben:In einem der Beiträge zur OT4XB wurde deutlich geschrieben, dass der Hersteller (hier Pablo) die neue C-API beachten und dann neu kompilieren muss.

aber wenn sich die Header nicht geändert haben ... was soll sich dann "ändern" ?

In beiden Fällen wurden von Alaska unsere Aussagen bislang wohl nicht überprüft und wir haben immer noch keine "korrekten" Antworten ...

Werner_Bayern hat geschrieben:Aber ich kann doch nichts an Alaska schreiben, was ich nicht selber überprüft / festgestellt habe...

es geht doch in diesen Thread um die Frax Probleme und "die" könntest du doch mal im Alaska-Forum posten da du doch die Probleme hast.

Es gibt im Alaska-Forum ja noch keinen aktuellen Thread zu Frax + Xbase++ v2.x und ich halte es für eine wichtige Informationen die andere Frax User haben sollten. je mehr Frax User sich mit Problem melden desto genauer könnte man das Problem eingrenzen.

AUGE_OHR hat geschrieben:Es gibt im Alaska-Forum ja noch keinen aktuellen Thread zu Frax + Xbase++ v2.x und ich halte es für eine wichtige Informationen die andere Frax User haben sollten. je mehr Frax User sich mit Problem melden desto genauer könnte man das Problem eingrenzen.

Jetzt schon
Dein Info-Argument hat mich überzeugt. Obwohl ich mir da nicht viel erwarte, da ist der Weg von Andreas schon erfolgversprechender.

AUGE_OHR hat geschrieben:hast du einen Beitrag in den letzten Jahr von mir im Alaska Forum gesehen ...

Woran liegt das? Kann man da nur mit aktiver Subscription was schreiben, ansonsten nur lesen?

Werner_Bayern hat geschrieben:Jetzt schon

JA ... gesehen

Werner_Bayern hat geschrieben:Dein Info-Argument hat mich überzeugt. Obwohl ich mir da nicht viel erwarte, da ist der Weg von Andreas schon erfolgversprechender.

zumindest ist es jetzt manifestiert und andere Frax User sind vor-gewarnt. Nun liegt es an weiteren Frax User ebenfalls ihr Problem im Forum zu schildern oder zumindest deine Beobachtungen zu bestätigen um das Thema weiter zu "boosten" denn eine Antwort von Alaska steht ja noch immer aus.

Steffen F. Pirsig
25. November 2014
public.xbase++.support.de
Re: Frax Reportgenerator und Xbase++ 2.0

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.

hm ... ich finden KEINEN Unterschied in den Header Dateien ... oder was ist damit gemeint ?

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.

wenn ich Frax User wäre ...

Er schreibt ja:

Die CAPI Funktionen _conType(), _conTypeA(), _partype() und _paratype() liefern in der 2.0 andere numerische Werte zurück

Also Funktionen die andere Werte liefern (), und das wegen der künftigen UNICODE Unterstützung. Das muss man nicht unbedingt im Header erkennen. IMHO ist das eine vernünftige Erklärung (mit dem Rest im original Posting in der Newsgroup).

satmax hat geschrieben:Er schreibt ja:

Die CAPI Funktionen _conType(), _conTypeA(), _partype() und _paratype() liefern in der 2.0 andere numerische Werte zurück

Also Funktionen die andere Werte liefern (), und das wegen der künftigen UNICODE Unterstützung. Das muss man nicht unbedingt im Header erkennen.

hm ... der Type der C-API Funktionen wird im Header mit ULONG (Vorzeichenlose 64-Bit-Ganzzahl) angegeben und hat sich NICHT geändert (zumindest das was wir User bekommen haben)

satmax hat geschrieben:IMHO ist das eine vernünftige Erklärung (mit dem Rest im original Posting in der Newsgroup).

meinst du jetzt das undokumentierte “SubTyping” ?

Eigentlich alles zusammen, ich habe echt den Eindruck Alaska nimmt das ernst und bemüht sich, obwohl sich bisher nur 2 User gemeldet haben.

Mit solchen Aussagen machen Sie doch deutlich das Sie die Sache ernst nehmen:

1.1) Wir haben durch Disassemblierung sowie “debugging” der FRSyst.dll die in Position 1 getroffene Aussage bewiesen.

(Wenn's interessiert, am besten komplett in der Newsgroup lesen: "Frax Reportgenerator und Xbase++ 2.0")

Aber ich habe als nicht FRAX Anwender eventuell nicht den richtigen Blick dafür. Auch habe ich mitbekommen das sich da in der Vergangenheit so manches aufgestaut hat. Mein Motto: schau nach vorne, vergangenes ist vorbei. Zumindest die Richtung dürfte aktuell stimmen.

Also ich finde die Antwort von Steffen sehr aussagekräftig, die Ursache ist geklärt und überprüft und: Er kommt uns da sehr entgegen.

Ein Kompatibilitätsschalter allgemein, also auch für andere Drittprodukte geeignet und die Prüfung, ob sie das in die 3er-Version ein gutes Stück mit integrieren.

Mehr kann man m. M. n. nicht erwarten.

@Andreas: =D>

Ich bin ebenfalls kein Frax-User. Aber ich finde es enorm, das Andreas sich da wirklich persönlich reinhängt. Ich finde es bedauerlich, das Spirins Witwe aus welchem Grund auch immer nicht verhandlungsbereit ist. Ich finde es super, das Alaska 1) einen Kompatibilitätsschalter dafür einbaut und 2) den zu kommenden Reportgenerator soweit ergänzt, das die Frax-Reportdateien weiter nutzbar sind. Auch das ist Investitionsschutz.

Man kann Alaska ja eine Menge vorwerfen, manches zu Recht, manches zu Unrecht, Aber hier haben sie wirklich Kundennähe bewiesen. Ich hätte mir nur gewünscht das die internen Änderungen auf Grund der Umstellungen auf die Unikode-Unterstützung besser kommuniziert worden wären, damit User und Entwickler rechtzeitiger informiert gewesen wären. So gab es hier hitziger Diskussionen, und viel Arbeit wurde von manchem in die Lösung der plötzlichen Frax-Inkompatibilität investiert, die durch eine rechtzeitigere Info hätten vermieden werden können.

Jan

Jan hat geschrieben:Ich hätte mir nur gewünscht das die internen Änderungen auf Grund der Umstellungen auf die Unikode-Unterstützung besser kommuniziert worden wären, damit User und Entwickler rechtzeitiger informiert gewesen wären. So gab es hier hitziger Diskussionen, und viel Arbeit wurde von manchem in die Lösung der plötzlichen Frax-Inkompatibilität investiert, die durch eine rechtzeitigere Info hätten vermieden werden können.

=D>
... hoffentlich bekommen wir jetzt die Informationen wie/wann wir den Kompatibilitätsschalter anwenden müssen.

Das Build 575 ist raus. Inkl. Kompatibilitätsschalter, und Anleitung, wie der zu verwenden ist.

Aber so wie ihc das verstehe, ist dann ALLES auf Kompatibilität geschaltet. Nicht nur Frax. Ob man das dann wirklich will?

Abgesehen davon: Mindestens seit vergangener Woche ist die Frax-Homepage abgeschaltet. Da ist also wohl definitiv garnichts mehr zu erwarten. Oder hat die Witwe von Sergei das alles an jemanden anderen verkauft, der das weiter führen wird? Fragen über Fragen, und keine Antworten.

Jan

Dazu steht auch was in der Mail, die von Alaska kam.

Viele Grüße,
Martin

Martin,

was steht denn da noch drin? Das Frax definitiv nicht weiter entwickelt wird? Könnte man aber auch so sehen, das Frax von Fam. Spirin nicht weiter entwickelt wird. Aber das ist alles nur Spekulation, man muß sehen was kommt. Ich denke aber, wenn es denn einen Nachfolger gibt wird der es schwer haben. Zu lange ist es nicht weiter gegangen mit dem Produkt.

Jan

Ich zitiere mal aus der Mail von Alaska den relevanten Teil:

Alaska Software, Inc hat geschrieben:Abschliessend noch der dringende Hinweis an alle FRAX Benutzer sich darauf vorzubereiten in den nächsten 12-24 Monaten auf ein alternatives Produkt zu wechseln. Der Hersteller des FRAX Report-Systemes hat seinen Geschäftsbetrieb eingestellt. Eine Wartung und/oder Weiterentwicklung wird es definitiv nicht geben.

Viele Grüße,
Martin

Andreas hat seine misslungenen Versuche mit Frau Spirin hier erläutert.
Das Produkt ist End of Life, wie man so schön sagt.