hi,
Tom hat geschrieben:
xHarbour ist Clipper-kompatibel, aber keineswegs Xbase++-kompatibel. Es gibt in vielen Bereichen signifkante Unterschiede zwischen beiden Dialekten, da unterschiedliche Wege gegangen wurden, um die Erweiterung der Sprachen für die Windows-Welt abzubilden.
Ich denke man muss es unterteilen.
Die "Engine" ist Cli*pper kompatibel genauso wie Xbase++ es zu 99,99% ist.
Der Unterschied liegt "nur" in der (verwendeten) GUI
Tom hat geschrieben:
Selbst ohne eXpress++ dürfte es Dir schwerfallen, aus Deinem Xbase++-Code direkt eine lauffähige xHarbour-Anwendung zu erstellen.
sorry Tom, aber das ist nicht richtig.
Es ist wiederum das Problem der GUI (von Hybrid sprechen ich nicht weil 99,99% kompatible)
auch die Classy Syntax mit ":" als send Operator stellt mit der richtigen GUI (=OOP) kein Problem
mehr da.
Tom hat geschrieben:
Und übrigens besitzt Du den Quellcode von eXpress++. Wenn also beide Sprachen kompatibel wären (was sie nicht sind), wäre das ein nachrangiges Problem.
und deshalb ist es grundsätzlich möglich, man muss "nur" die Superclass(en) "austauschen"
Tom hat geschrieben:
Es ist allerdings denkbar, die Sprachunterschiede mit Hilfe diverser Präprozessor-Direktiven auszugleichen. Was für ein Aufwand das wäre (und ob es möglich wäre), weiß ich allerdings nicht. Irgendwer hatte meiner Erinnerung nach mal in Rogers Forum gefragt, ob seine Bibliotheken auch mit xHarbour neu kompiliert werden könnten, und er hat das nach entsprechender Prüfung verneint.
wie schon gesagt der Stand (2006) ist überholt. Es ist grundsätzlich möglich nur müsste sich
jemand die Arbeit machen und die #xtranslate einbauen ...
Code: Alles auswählen
#xtranslate WvgDialog => XbpDialog
#xtranslate WvgStatusBar => XbpStatusBar
#xtranslate WvgStatic => XbpStatic
#xtranslate WvgActiveXControl => XbpActiveXControl
#xtranslate WvgPushButton => XbpPushButton
#xtranslate WvgComboBox => XbpComboBox
#xtranslate WvgTreeView => XbpTreeView
#xtranslate WvgMenu => XbpMenu
#xtranslate WvgToolBar => XbpToolBar
#xtranslate WvgMenuBar => XbpMenuBar
diese aus der GTWVG benutze ich z.Z. und es funktioniert 1:1 ohne Probleme (naja ab und zu
stimmt was optisch nicht ganz, aber man braucht schon die Bildschirmlupe um es zu sehen)
Ich habe also längst noch nicht "alle" Parts ausprobiert, aber ich gehe mal davon aus das Pritpal
bei den anderen Parts genauso gut gearbeitet hat, den als Xbase++ User "kennt" er es ja.
Wie ja jeder wohl weiss ist Harbour selbst open Source also free. Allerdings muss man sich dann
alles selbst "zusammenstellen" und configurieren was für einen Newbie nicht ganz einfach ist.
Deshalb gibt es Distributionen wo man "out-of-the-box" Zusammenstellungen erwerben kann und
man auch dort Support bekommt. Ich werde auf dem Usertreffen ein solches Paket vorstellen und
jeder kann sehen wie gut und schnell man einen Xbase++ Code "dualfähig" machen könnte ...
Ich muss aber nochmals darauf hinweisen das ich Harbour nur deshalb benutzte weil Xbase++
an solchen Stellen versagt hat (activeX, Threads etc.) und ich mich nicht von der Arbeit abhalten
lassen wollte. Ich will also NICHT auf Harbour "umsteigen" (wenn man mich nicht dazu zwingt),
sondern aufzeigen das es sowohl für die XbParts als auch für die "Engine" die Möglichkeit gibt die
"auszutauschen". Wenn also das "Werkzeug" Xbase++ versagt und Cl*pper nicht ausreicht (GUI)
dann gibt es jetzt eine 3th Möglichkeit seinen Source Code zu verwenden OHNE was zu ändern.
Nachtrag : bitte nun kein Diskussion Harbour
.OR. Xbase++ sondern mal an ein
.AND. denken !