Inoffizielles deutsches Xbase-Forum

Hi,

ich habe nichts gefunden was nicht läuft bei meinen Programmen und Fremd-DLL binde ich mit PRG ein.
Aber irgendwie kann ich es nicht glauben

Habt Ihr Hinderungsgründe für den Umstieg nach Xbase 2.0 von 1.90.355 gefunden ?

Hallo Hubert,

ansich hat der Umstieg bei mir auch gut geklappt. Ich hatte Probleme mit den Browses. Alaska hat da einiges rumgeschraubt. Bei den PP haben die alte Fehler ausgemerzt, was dann aber bedeutete, das die alten falschen Sachen bei mir nicht mehr liefen. Den beim Scrollen nicht mitlaufenden Zeilencursor mußte ich umschreiben, dafür gibt es zum Glück den Kompatibilitäsparameter.

Äußerst positiv überrascht hat mich aber die Sache mit ASINET. Da gibt es jetzt andere dll zum Enibinden. Und die Workbench bindet automatisch bei den entsprechenden alten #pragma-Anweisungen die neuen richtigen dll ein, und gibt im Statusfenster eine Meldung aus, das man die doch bitte ändern möge. Das war mal so richtig gut mitgedacht.

Ansonsten - zumindest bei mir, der ich nicht in die tiefsten Tiefen der Xbase++-Programmierung abgestiegen bin, gab es keine Probleme. Ich weiß aber von einigen Powerusern, das die schier am verzeifeln sind wegen allzu vieler Fehler im Unterbau. Da sind meine kleinere Mäkeleien wegen einiger Fehler in der Workbench schon geradezu zu vernachlässigen.

Jan

Frage andersherum gestellt, warum umsteigen? Das wäre viel interessanter. Ich überlege nicht warum ich mir irgendwas NICHT kaufen soll, sondern WARUM ich es kaufen sollte. Der Verkäufer findet immer einen Grund um was neues zu verkaufen, aber das ist ja nicht die Frage an sich. Ansonsten kaufe ich mir jeden Tag irgendwas neues.... nicht wahr?

Manfred,

da die Prof Sub längst bezahlt ist ... ist ja schon gekauft.

Ich wollte nur sicher gehen, dass ich keine Fehler übersehen habe und nach einem Jahr (etwa) ist es schon sinnvoll auf die neue Version umzusteigen

Manfred,

wenn man "ganz normal" vor sich hin programmiert ist die 2.0 sicher nicht notwendig. Aber ich bin z. B. zur Zeit schwer am Schreiben einer Touch-Kasse und einer Lageristen-Führung. Da kann ich unglaublich gut mit den HTML-Klassen arbeiten. Ja sicher, das ginge auch irgendwie mit Standard-Elementen. Aber da wäre das um Welten komplizierter. Und ich habe ja auch nicht umsonst vergangenes Jahr in Potsdam über die DataObjects gesprochen. Die möchte ich ums Verrecken nicht mehr missen. Ich weiß, Du hast Dir da zumindest für den Datenbankzugriff was eigenes geschrieben. Aber wie viel Zeit hast Du da rein gesteckt? Ich möchte das nicht machen, die Zeit steck ich lieber in andere Arbeiten. Die zeit, die ich mit der Programmierung passender Klassen verbringen würde (Du weißt, ich tu mich mit Klassen ein wenig schwerer als Du), hab ich mit dem Preis der Subscription locker wieder drin.

Und leider wird es für die 1.9 keine Updates mehr geben. Ich kämpfe da z. B. mit einigen Problemen in der ASINET. Die werden in der alten Version nicht mehr angefasst, in der 2.0 bekomme ich aber die Korrekturen. Bei Weitem nicht so wie von Alaska versprochen (jeden Monat eins, mindestens), sondern eher seltener (in 2015 bislang genau 2 Updates, eines wird jetzt wohl noch kommen). Aber immerhin, es gibt was.

Jan

Man kann auch nicht erwarten, dass alte Versionen weiterhin gefixed werden.
Und wer zu lange wartet mit dem Umstieg, hat mehr Arbeit.

Ich lasse nur immer etwa ein Jahr vergehen bevor ich neue Versionen in Produktionsprogrammen zum Einsatz bringe.

Nochmal, ich habe über die prof sub eine aktuelle Version (wenn auch älter als erwartet )
Ich habe seit 1.90.331 bis 2.00.aktuelle Version alles auf der Platte, nur die Anwendungen auf unserem Citrixserver etc. laufen mit der 1.90.355 ...
die möchte ich bei Gelegenheit auf 2.00 anheben, wie auch die Standardeinstellung auf 2.0 setzen.

Sicherheitshalber wollte ich nur wissen ob es bekannte NO GOs gibt

Was mich abhält sind die vielen Programme, die ich im täglichen Einsatz habe.

Wenn ich nicht mit verschiedenen Umgebungen arbeiten will, die ich dann immer wieder mal umstellen muss, abhängig davon, welches Programm ich laufen lassen will/muss, dann bin ich da bestimmt zwei Tage mit compilieren und testen beschäftigt. Die Zeit will ich mir aktuell nicht nehmen.

Man kann auch nicht erwarten, dass alte Versionen weiterhin gefixed werden.

Doch, kann man. Das ist (in/bei Softwarehäusern) absolut üblich, vor allem in der (konkret vorliegenden) Situation, dass eine neue Version instabil ist und (noch) nicht den vorgegebenen Leistungsumfang enthält. Wenn ein Fehler vorgefunden wird, der die stabile Version und das "work in progress" betrifft, wäre normalerweise zu erwarten, dass die Korrektur in beiden Fassungen vorgenommen wird. So agieren wir auch. Es gibt eine Version, die als stabil gilt und für die es nur noch Hotfixes gibt (feature freeze), die andere (aktuellere) Version ist zwar freigegeben, erfährt aber neben Korrekturen auch noch Ergänzungen. Einige Softwarehäuser machen das auch für weitere Abstufungen.

Gründe gegen den Umstieg auf 2.0: Wie hier genannt. Xbase++ 2.0 ist nach meinem Dafürhalten immer noch eine Betaversion.

Gründe dafür: Es ist in einigen Bereichen deutlich schneller und der Leistungsumfang ist größer, wenn auch längst noch nicht an allen Stellen vollständig.

Hi,

beim Umstieg auf die 2 brauchts natürlich für alle Xbase Zusatz-DLL wie z.b. XB2Net, XbPDF usw. eine neue für Version 2 erstellte. Die auch bezahlt werden muss.

Ich habe umgestellt, hauptsächlich darum um Runtime-DLL mit aktuellem Datum zu haben. Die alten haben doch öfters zu peinlichen Fragen geführt......



Cu Carlo

ramses hat geschrieben:Ich habe umgestellt, hauptsächlich darum um Runtime-DLL mit aktuellem Datum zu haben. Die alten haben doch öfters zu peinlichen Fragen geführt......

Na, das ist ja mal ein interessantes Argument.

Jan

Tom hat geschrieben:

Man kann auch nicht erwarten, dass alte Versionen weiterhin gefixed werden.

Doch, kann man. Das ist (in/bei Softwarehäusern) absolut üblich, vor allem in der (konkret vorliegenden) Situation, dass eine neue Version instabil ist und (noch) nicht den vorgegebenen Leistungsumfang enthält.

...wobei ich mich an eine Diskussion aus 2014 erinnere, ob der Erhalt von Hotfixes nur via Subscription sinnvoll sein soll oder nicht.
Wenn ich Xbase einer alten Version einsetze aber kein Neues gekauft habe, erhalte ich keine Fixes. So werde ich mir kaum mehr eine neue Version anschaffen. Also hat dieser Support auch mit Marketing zu tun. Das ist wohl eine im Hause Alaska fehlende Abteilung.

Na ja, es werden in der Regel nur wichtige Fixes gemacht. Der Hersteller will ja, dass die neueste Version gekauft und verwendet wird - wenn die denn nicht im Beta-Stadium in sich selber veraltet...

Ich arbeite aktuell noch mit der 1.9er Version.
inzwischen seit Jahren ohne Subskription.
Solange diese nicht zeitlich sondern nach Updates/Versionen abgerechnet wurde
habe ich gerne den Subskriptionspreis bezahlt (ich bin seit der ersten Xbase-Version dabei)
Aber seit der Umstellung? Was erhält man als Gegenwert?
und nun die Version 2.0
Auch hier wurde wieder viel versprochen aber: Was davon wurde eingehalten?
Und warum dann auf eine imho Betaversion für viel Geld umsteigen?
Ich werde auch weiterhin abwarten bis der Zeitpunkt kommt wo es sich lohnt umzusteigen.
Wenn der nicht kommt werde ich mir halt eine Alternative suchen müssen...

Gruß Stefan

Hi

um gegenüber den eigenen Kunden "besser" da zu stehen sollte man Umsteigen so dass auch der Kunde eine Runtime sieht die nicht bis zu 10 Jahre alte DLL's enthält.

Objektiv betrachtet ist es jedoch schon der Hammer was die Version 2 bietet, zurück in die Steinzeit, Englische Manuals, Docs viele Texte der Apps nicht mehr in Deutsch viele Funktionen gar nicht beschrieben. Aber auch keine neuen Fehler/Probleme.

Dennoch hilft es Alaska wenn jeder User die aktelle Version verwendet. Nur so können Sie weiter machen bezw. Xbase++ weiterentwickeln, den die Xbase++ Programmierer werden sicher nicht mehr und ohne Geld in der Kasse geht auch bei Alaska nichts....

Ein Alternative zu suchen, wie Stefan schreibt wird nicht einfach eher unmöglich. Nein ist UNMÖGLICH!!!. Ich habe 1987 mit Clipper begonnen, viel Programme aus dieser Zeit laufen mit kleinen Anpassungen noch heute unter Xbase 2.0 im Textmode. Es gibt keine Alternative. Einzig: zusammen mit Alaska in Würde das Pensionsalter zu erreichen ..... Problem gelöst.


Cu Carlo

Hallo Ramses,

doch es gibt eine Alternative. Ich arbeite seit drei Jahren mit Visual FlagShip. Clipper
Programme können eifach übernommen werden. Dem Compiler sage ich dann durch
Parameter ob er es im CRT Modus oder im GUI Modus kompilieren soll und habe dadurch
mit gleichem Quellcode eine Windows Oberfläche.

Das alles ohne den lästigen Rutime *.dll's beim weitergeben eines Programm. Schau Dir
doch mal http://www.multisoft.de an.

Gruß Johann

Hallo Carlo,
mit eXpress++ ist der Umstieg sehr einfach möglich, nur minimale Anpassungen und viele zusätzliche Möglichkeiten bei fast gleichen Syntax. Das kann Flagship nicht mal annähernd bieten. Habs am Anfang auch mit Flagship versucht, vor allem für Linux, aber habs schnell wieder aufgegeben.
Grüße
Rudolf

Hallo Rudolf,

mit welcher FlagShip Version hast Du den gearbeitet? Ich Rede nicht von FlagShip für
Linux sondern Visual FlagShip 7 für Windows. Für Linux gibt es kein Xbase++ und auch
kein Express++. Auch Clipper Programme laufen nicht unter Linux.

Alte reine FlagShip Versionen unterscheiden sich erheblich von Visual FlagShip Versionen.

Gruß Johann

@Rudolf

ich will nicht umstellen, ich arbeite seit der ersten Version von Xbase++ mehr oder weniger zufrieden mit Xbase++. Ich wollte nur feststellen dass das Umstellen von Xbase Programm zu einem anderen Compiler meiner Meinung nach nicht möglich ist. (Jedenfalls nicht ohne sehr viel neu zu schreiben und zu testen.)

Cu Carlo

ramses hat geschrieben:Ich wollte nur feststellen dass das Umstellen von Xbase Programm zu einem anderen Compiler meiner Meinung nach nicht möglich ist. (Jedenfalls nicht ohne sehr viel neu zu schreiben und zu testen.)

klar gibt es die : harbour / xHarbour***
https://harbour.github.io/ Open Source
http://www.xharbour.com/ *** biete als Distribution 3 "Pakete" und Support an

harbour, als "cross-platform compiler", arbeitet wie ein "transpiler" oder "Source-to-source compiler".
ich erzeuge damit C Code welchen ich mit dem (alten) Borland Bcc32.EXE compiliere und mit Ilink32.exe das Windows EXE erstelle.

aber darum geht es in diesem Thread nicht und in Prinzip können nur User die v2.x einsetzten Aussagen machen was die "beta" kann/nicht kann.

ramses hat geschrieben:Ich wollte nur feststellen dass das Umstellen von Xbase Programm zu einem anderen Compiler meiner Meinung nach nicht möglich ist. (Jedenfalls nicht ohne sehr viel neu zu schreiben und zu testen.)

klar gibt es die : harbour / xHarbour***[/quote]
Selbstverständlich ist das moglich. Wie du richtig feststellst, braucht das Umschreibarbeit. Aber für diesen Fall ist ein Refresh ohnehin gut und so relativiert sich ein Wechsel. Wie ihr wisst, arbeite ich seit 2 Jahren mit Windev, kann sagen, dass ich die Xbase-Synax zu 70% übernehmen konnte. Die Einbettung in die GUI deutlich weniger, dies aber wegen dier vielen zusätzlichen Möglichkeiten und der IDE.

AUGE_OHR hat geschrieben:aber darum geht es in diesem Thread nicht und in Prinzip können nur User die v2.x einsetzten Aussagen machen was die "beta" kann/nicht kann.

Jimmy, doch. Wenn Tom als einer der in meinen Augen gewieftesten Programmierer die Version 2.0 als Beta bezeichnet, so kann eben nicht umgestiegen werden.

@Johann,
als Xbase++ Programmierer der ersten Stunde weiss ich natürlich auf welchem Betriebssystem es läuft und wo nicht. Für mich war nur interessant dass Visual Flagship auch auf Linux verfügbar ist. Ich habe eine normale Flagship Lizenz und hatte damals eine Testversion für Visual Flagship. Habe mich dann entschlosse ein wenig mehr Arbeit in die Umstellung von Clipper auf Windows zu stecken und dann eXpress++ verwendet. Irgendwann hätte ich sowieso umsteigen müssen da Visual Flagship nur eine minimalistische Umsetzung erlaubt. Solche Programme lassen sich nur mehr sehr schlecht verkaufen, die Kunden messen die Leistung eines Programmes eben auch zu einem großen Teil an der Benutzeroberfläche. Und Linux spielt keine große Rolle mehr bei mir für Desktopprogramme. Daher kann ich nur empfehlen gleich ein wenig mehr Zeit zu invstieren, dafür hat man eine Lösung die auch Zukunft hat.
Grüße
Rudolf

Herbert hat geschrieben:Wie du richtig feststellst, braucht das Umschreibarbeit.

es ist, von Cl*pper kommend, der selbe Aufwand wie mit Xbase++ da 99% kompatible.
erst bei GUI wird es komplizierter mit den verschiedenen Constribution und deren Syntax.
ich verwende die GTWVG von Bedi Pritpal, der selbst Xbase++ User war, dessen Controls zu 98% mit der Xbase++ Syntax arbeiten.

Herbert hat geschrieben:Jimmy, doch.

es ging um die "Alternativen" : Flagship, Windev oder harbour worauf ich nicht so ausführlich in "diesem" Thread eingehen wollte.

Frage: hat jemand Probleme mit visual Style in der v2.x ? benutzt jemand das neue CSS Style für die Optik ?

Jimmy,

ich habe für einen Kunden die XbpHtmlWindow() eingebaut, und da benutze ich auch CSS. Funktioniert sehr gut. Bei der Performance bin ich noch nicht zufrieden, da muß ich mal noch ein wenig rumschrauben.

Jan

Wenn Tom als einer der in meinen Augen gewieftesten Programmierer die Version 2.0 als Beta bezeichnet, so kann eben nicht umgestiegen werden.

Oh, das ist zu viel der Ehre und der Verantwortung. Und ich möchte explizit unterstreichen, dass ich den Beta-Status auf das (zugesagte) Featureset beziehe, vor allem auf die PostGresDBE und die WebUI - beides ist nach meinem Kenntnisstand noch unvollständig und nicht in komplexen Anwendungen nutzbar.

Tom,

nö Du bist sicher hier einer der Entwickler, die am Tiefsten in der Sprache drin stecken. Und sich auch nicht scheuen, ihre Meinung mal in klaren Worten auszudrücken. Wem auch immer gegenüber.

Aber zum Thema: Ich bin weit ab davon, so tief drin zu stecken wie Du oder andere Entwickler. Insbesondere die Tools-Entwickler wühlen naturgemäß sehr tief im Unterbau der Sprache und wissen daher sehr wohl, was da noch alles im Argen liegt. Aber meine persönliche Meinung zur 2.0 ist: Die ist sehr stabil. Die hat gegenüber der 1.9 SL1 einige sehr interessante Erweiterungen. Ich setze 2.0 die ohne Probleme bereits bei Kunden produktiv ein, auch einige der neuen Funktionen. Es ist also, mit "normalen" Mitteln genutzt, keine Beta mehr. Wie gesagt, in den Tiefen mag das teilweise anders aussehen, abre das tangiert meine Arbeit nicht.

Ich stimme Dir aber zu das manches, insbesondere die Funktionen, die die 2.0 ausmachen, noch im Rohzustand ist. Hattest nicht Du vor einigen Monaten zitiert, das Steffen in den USA angekündigt hatte, das es ein größeres Update wegen PostgreSQL geben wird - VOR der SWFox? Und ja, ich arbeite gerade mit der WebUI, bei einem Kunden ist das ein sehr guter Weg seine Wünsch umzusetzen. Schöne Sache das. Aber noch weit davon entfertn, die XBParts ablösen zu können. Was ja das Zeil von Alaska ist (nein. Falsch ausgedrück. Nicht ablösen. Parallel laufen)

Es gibt aber auch noch eine ganze Reihe anderer Fehler, die mit der 2.0 nicht behoben wurden. So viele PDRs sind noch offen, obwohl die betreffenden Fehler beileibe keine Lappalie sind. Auch das könnte man manchmal noch als Beta bezeichnen.

Insgesamt gesehen aber finde ich, das man mit der 2.0 seht gut arbeiten kann. Besser geht immer, aber es ist weitaus gut genug für produktives Arbeiten.

Jan