X Compiler

Es soll sie ja geben ...

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

X Compiler

Beitrag von AUGE_OHR »

hi,

also ich will hier nix gegen Xbase++ sagen, "i love it", aber manchmal macht mich das ++
dabei verrückt...

es gibt doch #IFDEF XPP ... wenn ich also einen Xbase (ohne ++) Code "so 1:1" übersetzte
"müsste" es doch genau so funktionieren ... ?

wie soll ich es bloss formulieren ... also ich komme mit Xbase++ nicht weiter aber der "selbe"
Code läuft mit einem "anderen" Xbase (ohne ++) Compiler/Linker ... so und nun ... ?

ja ich weiss um Schwächen von Xbase++, aber so PENG war mir das noch nie klar ...

vermutlich weiss keiner wovon ich überhaupt spreche und ich muss erst selbst einmal Luft
holen ... es geht und es geht nicht ... mit Xbase (++) der Codejock Calender und Resources

2 Demo´s als Exe, eins läuft und das andere versagt (kläglich ++) ... eindeutiger kann man
wohl einen Xbase++ BUG kaum nachweisen !!! ... Mist und nun wieder warten auf einen Fix von Alaska (Demo1 schon lange raus)

... und wenn man das nun "selbst beheben" könnte ... ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: X Compiler

Beitrag von AUGE_OHR »

hi,
AUGE_OHR hat geschrieben: also ich will hier nix gegen Xbase++ sagen, "i love it", aber manchmal macht mich das ++
dabei verrückt...

... und wenn man das nun "selbst beheben" könnte ... ?
will keiner auf den "Dream" zusteigen ? Träume können war werden !!!

Als ich mit Cl*pper programmiert habe, konnte ich nicht besondere gut mit den M$ Fox Leuten,
aber deren X Code sieht unserem Xbase++ ja nicht "so" unähnlich das man nichts erkennen würde.

Bei Xbase++ ist mir damals sofort der Class(y) Style aufgefallen den ich ja kannte und das ist
wohl auch der Hauptgrund für mich warum ich Xbase++, nach langem suchen, ausgewählt habe.

i have a Dream ... was wäre wenn ... ich nur eine #Include einbinden müsste ...

für mich als Cl*pper Programmierer war der Einstieg (Hybrid) ja recht schnell weil Xbase++
"meinen" Code "anerkannte" und das machte was ich wollte (naja 99,9%). Also gab es da weder
"grosse" Arbeit noch viel zu "lernen". Das ging erst mit GUI los ... was ist ein XbPart ...

inzwischen denke ich ist das vielen Xbase++ User die XbParts so wie die Cl*pper Befehle
geläufig sind das man sich gar keine grossen Gedanken mehr darum macht.

nun komme ich über Express++ auf den Gedanken (bitte lasst mich ausreden), das es den
Usern doch eigentlich darum geht das "ihr" Code funktioniert. Ob man dafür XY oder sonst
was verwendet ist doch im Prinzip egal, oder ?

mit XJockcode haben alle, besonders die Express++, User die Möglichkeit "ihren" Source zu
erweitern. Das selbe hab ich ja für "pure" Xbase++ vor und da wird es dann auch eine LIB/DLL
geben. Was ich euch dort gebe wird ja nur die interessieren die auch den Source haben wollen.

wenn man nun, per #Include, die CJ Parts aktivert dann werden ja die XbParts dadurch ersetzt.
man könnte also durchaus "behaupten" das nur ein Teil davon Xbase++ wäre ... der Rest ist
activeX wo gegen auch nichts einzuwenden ist, oder ? (XbpToolbar, XbpStatusbar sind auch
aktiveX)

also wenn man die in diesem Fall "überschrieben" hat, "könnte" man die doch auch in Xbase++
so "aufteilen" das sie mit in die C:\Alaska\XPPW32\source\DLL\LIB\XPPSYS.DLL (SL1 v350)
kommen die man sich ja selbst zusammen stellen kann. weniger Code = weniger Fehler ...

Das wäre doch ein sinnvoller Vorschlag für Alaska und gäbe und die Möglichkeit "selbst"
Einfluss auf den Code zu nehmen. (jetzt hab ich Zugriff auf die SuperClass )


wer mir bis hier folgen konnte den möchte ich nach "dem nächsten Schritt" fragen ?
wo könnte/wollte/sollte man ansetzen um mehr Alternativen zu bekommen ?
was gibt uns (pure) Xbase++ an Möglichkeiten (DllCall, activeX) um noch mehr aus der "Kiste" rauszuholen ?
eigenen DBEsys Treiber schreiben, einbinden per ?

... und was wäre für Xbase++ User notwendig auf eine "andere" Kiste ... nein nicht umsteigen,
sondern "dual" verwenden ... so wie ich HybridCode ja weiter mit Cl*pper nutzen kann ? 99,9%

wer will bei den Gedanken "Spielen" mitspielen ?
gruss by OHR
Jimmy
Benutzeravatar
Markus Walter
Programmier-Gott
Programmier-Gott
Beiträge: 1018
Registriert: Di, 24. Jan 2006 10:22
Wohnort: Saarland

Re: X Compiler

Beitrag von Markus Walter »

Hi Jimmy,

ich bin ja für Gedankenspiele immer zu haben, aber ich verstehe noch immer nicht, auf was Du hinaus willst.
Gruß
Markus

Mitglied der XUG Saarland-Pfalz
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: X Compiler

Beitrag von Jan »

Markus hat geschrieben:ich bin ja für Gedankenspiele immer zu haben, aber ich verstehe noch immer nicht, auf was Du hinaus willst.
Das hast Du schön gesagt. Ich hatte mir das schon beim ersten Posting von Jimmy gedacht. Und als ich heute morgen das zweite von ihm sah dachte ich, jetzt wird das alles klarer. Tja, falsch gedacht :badgrin: .

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9343
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 358 Mal
Kontaktdaten:

Re: X Compiler

Beitrag von Tom »

Wenn ich Jimmy richtig verstehe, geht seine Idee dahin, insbesondere bei GUI-Code Lösungen außerhalb der Darstellungsklassen von Xbase++ zu suchen, um a) fehlerfreier, b) flexibler und c) leichter portierbar zu sein. Wenn man in seinem Xbase-Code keine XbaseParts benutzt, sondern sowieso auf AX-Klassen und -Komponenten wie Codejock zurückgreift, wird der Code "allgemeiner", also weniger abhängig von dem, was Xbase++ unter der Haube macht - und theoretisch simpler portierbar, weil die AX-Komponenten bleiben können. Ich weiß nicht, wie und ob das gehen soll, aber den Ansatz verstehe ich durchaus.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: X Compiler

Beitrag von AUGE_OHR »

hi,
Tom hat geschrieben:Wenn ich Jimmy richtig verstehe, geht seine Idee dahin, insbesondere bei GUI-Code Lösungen außerhalb der Darstellungsklassen von Xbase++ zu suchen, um a) fehlerfreier, b) flexibler und c) leichter portierbar zu sein. Wenn man in seinem Xbase-Code keine XbaseParts benutzt, sondern sowieso auf AX-Klassen und -Komponenten wie Codejock zurückgreift, wird der Code "allgemeiner", also weniger abhängig von dem, was Xbase++ unter der Haube macht - und theoretisch simpler portierbar, weil die AX-Komponenten bleiben können.

Ja genau das ist doch möglich wenn man "Alternativen" hat.
Und wenn es nicht funktioniert kann man ja die #Include wieder rausnehmen und man hat wieder
"pure" Xbase++
Tom hat geschrieben: Ich weiß nicht, wie und ob das gehen soll, aber den Ansatz verstehe ich durchaus.
naja ... so wie Express++ ... #Include mit #xtranslate und xCommand ...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: X Compiler

Beitrag von AUGE_OHR »

jetzt muss ich mal eine Frage stellen : Kann man einen eigenen DBEsys "Treiber" schreiben ?

ich kann das sowieso nicht, aber ich denke da wieder an Cl*pper NTX und dann kam SixDrive CDX
klar wird das nicht ohne Hilfe von Alaska gehen, es interessiert mich bloss ob es jemand mal
versucht hat oder weiss ob es überhaupt möglich ist ... ich muss ja nicht jedes AX ausprobieren.

... der ADS von Alaska ist doch im Prinzip eine 3PP Anbindung ... ?
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9343
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 358 Mal
Kontaktdaten:

Re: X Compiler

Beitrag von Tom »

Hallo, Jimmy.

Die Idee hat was. Man reduziert seinen echten Xbase-Code auf den "kaufmännischen" Anteil, von dem man prinzipiell auch erwarten kann, dass er mit anderen X-Dialekten funktioniert, und lagert alles, was GUI ausmacht, derart aus, dass es portabel wird. Das ist ja eigentlich auch der Ansatz der Windows-Forms.
Kann man einen eigenen DBEsys "Treiber" schreiben ?
Vermutlich meinst Du damit, eine eigene DBE zu schreiben, also alle Tabellenzugriffsfunktionalitäten - von USE bis SEEK - zu überlagern. Meiner Meinung nach reicht dafür eine Änderung der DBESYS.PRG nicht aus - die ist nach meinem Verständnis dafür zuständig, die verschiedenen DBEs verfügbar zu machen. Eine DBE überlädt die Kommandoschicht für die allgemeingültigen Kommandos (von USE bis SEEK) und setzt sie entsprechend um. Das macht z.B. die ADSDBE oder die ODBCDBE. Man müsste eine eigene [x]DBE.DLL entwickeln. Dafür bräuchte man m.E. Spezifikationen, die (bisher) nicht öffentlich sind.
Herzlich,
Tom
Antworten