sollte was so angefallen ist beheben.
Dlls erstellen geht noch nicht zu 100%....
Was heisst das genau? Der Befehl kommt erst, wenn du ihn zu 100% lauffähig hast ?
Kleiner tipp dir crt2.o aus dem lib ordner bei win32 solltest du entweder in dllcrt2.o umbenennen damit man auch dll´s kompilieren kann
aufrufen dann mit declare oder wie?
Hoppla, die hab' ich vergessen. Kommt im nächsten Update. GLBasic Befehle wie Grafik usw. gehen warscheinlich 90% noch nicht.
Schade :D aber gehts dann mit Declare in Inline, oder machst du da auch einen GLBasic Befehl?
So. Update online.
Man macht einfach ein Projekt, und schreibt oben dann:
EXPORT funktionsname
Dann hat man eine DLL, die "funktionsname" exportiert.
aha, und der Import? Wie gehabt mit Inline?
Ein paar kurze Erklärungen dazu wären nicht ganz verkehrt ;) Auch die Hilfe ist nicht aktualisiert, soweit ich das sehe.
Jow weil der Befehl noch in der "Betaphase" ist denke ich :D
Aber wie macht man jetzt nun den Import aus der DLL ?
GLBasic Befehl, oder Inline und Declare ?? <-----------------------
Ja, klar. Eine DLL läd man wie bisher. Ich werde versuchen ein Programm zu machen, das aus einer DLL einen gbas Wrapper machen kann.
Für was ist dann DLLCALL?
bzw. kannst mal ein kleines Beispiel machen?
DLLCall ist tot. Das war eine Vorstufe zu DECLARE.
Wieso ist der Befehl dann noch drin ?
Kompatibilität?
*gäääähn* lang ists her das ich was schrieb ;)
du hast wie ich gesehen hab die einstiegspunkte der dll verschoben um die von dll nur von glbasic nutzbar zu machen. nun wäre ein kleines tool nicht schlecht das die exporte auflöst und anzeigt so wie es mein pe explorer eigentlich tat bevor die demo abgelaufen ist ;)
und soetwas in der art wie bei dem bilder laden die man einfach in die ide kopierte und da gleich LOADSPRITE vor war. nur das wenn man die dll reinkopiert ein kleines fenster aufgeht in dem die funktionen zusehen sind die exportiert werden und man die auswählen kann. der die dann lädt mit dem ganzen code zeugs. wär das nich klasse? ^^
Was hab ich verschoben? Die Funktionen werden alle mit extern "C" __stdcall exportiert - so wie die Windows API auch.
Ich schau mal, ob ich für GLBasic exporte gleich einen Wrapper miterzeugen lasse, damit man die DLL in ein Projekt integreiren kann. Aber das dauert noch, weil ich z.Zt. privat viel um die Ohren hab und das mit der DLL noch nicht so recht läuft.
hmm also wenn ich die dll mit sonem freeware dll export anzeige tool öffne sagt der kein einstiegspunkt gefunden. ich konnte leider nicht mit pe explorer testen der würde das sicherlich finden aber die testversion ist wie gesagt abgelaufen. aber wenn du sagst es sind normale exports dann werd ich mal weiter testen.
Schon mit shift-F8 als DLL erstellt, ja?
ja und die bringt nichtmal eine Function richtig zurück wie es scheint.
FUNCTION Plus: X,Y
E = X+Y
RETURN E
ENDFUNCTIONdie mit EXPORT Plus und Shift+F8 erstellt
dann mit Declare aufgerufen:
INLINE
DECLARE(Plus,"Dll-Test.dll",(int,int),int);
if(Plus>0){
PRINT("GEHT",10,10); // Als test ob se geladen wird
}
LOL = Plus(10,20);
PRINT(LOL, 100,10);
ENDINLINEAusgabe ist 20, aber wieso?
Hähä! Schreib mal:
EXPORT Plusin Dein DLL Projekt.
2. GLBasic Zahlen sind vom Typ "DGInt". (Das ist i.d.R. "double", aber schreib ruhig DGInt).
3. if(Plus>0) könnte falsch sein, wenn er Plus als 'int' vergleicht. Mach: if(Plus) oder if(Plus!=0)
4. Ausgabe ist 20, weil FUNCTION Plus im Projekt ist?
Ich bin verwirrt o.O
könntest du mal ein kleines Beispiel schreiben mit einer Simplen Function ?
also:
EXPORT Plus
FUNCTION Plus:
X+Y
ENDFUNCTIONund zum aufruf dann halt die
INLINE
DECLARE(Plus,"Dll-Test.dll",(int,int),DGint);
if(Plus){
PRINT("GEHT",10,10); // Als test ob se geladen wird
LOL = Plus(10,20);
PRINT(LOL, 100,10);
}
ENDINLINE
Hi ..
das ist aber alles ziemlich weit weg von bestehenden Basic Konventionen, Kann man denn da überhaupt noch von einem Basic reden. Siet mir stark nach Obewron aus. Wenn das noch jemand kennt.
Oberon? War das nicht mal als Nachfolger von Modula-2 gedacht? Glaube mich dunkel daran zu erinnern.
Aber stimme dir zu. Das ist alles andere als komfortabel. Dieser C++ / Basic-Mischmasch kann mich auch nicht gerade zu Begeisterungsstürmen hinreißen.
OK. Bitte einen Vorschlag, wie man solche Funktionen in GLBasic einbinden soll.
;) gute Frage
das mit EXPORT für die DLL-Erstellung ist ja schon recht schön einfach.
Das Einbinden wäre idealerweise ebenso einfach möglich, halt GL-like
Beispielsweise mit einem Befehl CALLDLLFUNC
Beispiel:
CALLDLLFUNC(
, , (param1, param2, ...))
natürlich auch nicht so schön wegen Parameterliste
Oder als Blockbefehl
BEGINUSEDLL
FUNCTION blabla(x, y)
FUNCTION nixnutz()
ENDUSEDLL
nach dieser Deklaration können die Funktionen wie normale GL-Basic-Funktionen genutzt werden.
Hmm.. oder:
IMPORT "dllname" funktionsname: param1, param2, ... ?
Zumindest für GLBasic funktionen wäre das gut.
jo, IMPORT wäre wohl noch besser, passt dann auch zu EXPORT ;)
wenn man allerdings dadurch wieder zweigleisig fahren müsste mit EXPORT für GL-DLL's und INLINE für C++-DLL's .... wäre nicht so prickelnd IMHO
Bei allgemeinen DLLs kommt man um INLINE nicht herum, weil es da eben verschiedene Datentypen gibt, die man u.U. anders gehandhabt haben möchte. Für Newton habe ich z.B. im Hintergrund eine kleine Liste mit Zeigern auf TYPEs gehalten und für die GLBasic Schnittstelle dann den Index in der Liste zurückgegeben.
Aber davon abgesehen, das darf ruhig bisserl kompliziert sein, weil's ja nicht der Normalfall ist.
hmmm tja, stimmt auch wieder ... na dann gefiele mir der Vorschlag mit IMPORT noch am besten. Vielleicht hat ja noch jemand andere Ideen.
Aber import macht dann ja nichts anderes als Declare oder liege ich da falsch?
also nochmal grundsätzlich:
// Programm : DLL-Test
EXPORT Test // Nur um die DLL zu erstellen !
WHILE TRUE
// GLBasic Code
SHOWSCREEN
WEND
END
FUNCTION Test: X,Y
E = X+Y
RETURN E
ENDFUNCTION
// Weil mans braucht.....
FUNCTION foo:
ENDFUNCTION
INLINE
Declare(Test,"DLL-Test.dll",(int,int),int);
If(Test){
Test(10,30);
}
ENDINLINEIst das so im Groben richtig?
so wie ich das jetzt verstanden habe, ja. Nur natürlich nicht alles in einem Quellcode
1. DLL erstellen
EXPORT test
FUNCTION test: x, y
RETURN x + y
ENDFUNCTION2. Aufruf im programm
IMPORT "test.dll", test: x, y
PRINT test(10, 15)
SHOWSCREEN
Hi ...
IMPORT_DLL("LIBNAME.DLL";"FUNKTIONNAME",par1 as Int, par2 as Int, par3 as float,return as int)
Var=CALL_DLL("FUNKTIONNAME",par1,par2,par3)
Die anzahl Parameter wird durch den IMPORT festgelegt, und CALL_DLL wird beim Compilieren auf gültigkeit geprüft.
Solte eigentlich nicht so schwer sein. Ansonsten schau dir doch mal GFABASic an, Das gibts jetzt umsonst.
hmm ich find die möglichkeit von c++ in nem basic ganz klasse. weiß gar nicht was ihr habt. und vorallem so eine devumgebung wie glbasic sie ist schafft ihr nichmal in 20 jahren zusammenzuschustern ;)
was ich damit sagen will ist ganz einfach das glbasic eine offene basic variante ist, die durch INLINE erweitert werden kann. ich hab damit auch schon reine c++ anwendungen gemacht trotzdem blieb es einfach. also nich meckern.
zum anderen will ich gern mal die mac os x sache ansprechen (ich arbeite noch am cross compiler der will aber libjava nich) wäre es nicht möglich eine umgebung auch auf dem mac zu machen? praktisch die ide und einen mac compiler bzw den von xcode. denn nicht jeder mac user wird einen intel mac haben oder einen win pc. das wäre noch ein anlaufpunkt für die mac entwickler.
zu der funktion die die dll laden soll, bin ich für die IMPORT foo: param1, param2 für glbasic funktionen. für c++ funktionen sollte man entweder ne erweiterte IMPORT funktion haben in dem man den typ mit angeben kann oder halt das DECLARE lassen.
Danke turricade. Sehe ich auch so mit IMPORT/DECLARE. Auch wenn's bisserl verwirrt. Evtl. mache ich beim Erstellen einer DLL einfach eine gbas Datei, die man blos dazupacken muss. Wäre ja auch leicht.
Die IDE unter Mac ist unmöglich. Die ist in MFC gemacht und hat ewig viel Arbeit gekostet. Evtl. bekommt man's mit WINE hin, aber da flippt der Compiler derzeit noch aus. :/
Problem mit wine ist einfach nur die das man auf dem ppc kein x86 code emulieren kann. somit scheidet das aus. eine ide könnte ich dir im cocoa framework zaubern jedoch müsstest du den rest machen. würde dir mein ibook zur verfügung stellen (per remote tag und nacht).
p.s. was habt ihr alle heute mit meinen namen? ich schrieb heute ne mail mit meinem namen unter und bekamm als antwort dann: Sehr geehrter Herr Tohnnaagel....
Tohnnagel LOL
Mach dir nix draus, geht mir täglich so, obwohl ich nen aus Deutschland stammenden Namen habe.... Mein alter Herr dreht da immer voll am Rad... :D
Hi ...
@trucidare .... du hast sicher recht. Es ist halt wichtig welche Ziehlgruppe @GernotFrisch
ansprechen will. Wenn er einen Hybriden mit der recht gewöhnungs bedürftigen C++ Architekture machen will. Ist das OK. Ich als reiner Basic verwender (Und Registrierter benutzer), brauche andere dinge als jemand der GLBasic als reine lowlevel SDK benötigt, und andere dinge sowiso in C++ macht. In Basic ist die vorgehensweise so wie @Quentin vorgeschlagen hat, am einfachsten für den anwender. Und @GernotFrisch hat sich an die Fahne geschrieben mit GLBasic eine leichte Sprache zu kreiren. Ich weis das es nicht einfach ist die ständigen Wünsche der anwender zu befriedigen. Aber kompliziert kann man es auch mit GNU C haben. Es gibt da eine Lektüre. Die da heist. STANDART OF BASIC.
Ich möchte damit die leistung von @GernotFrisch keinesfals schmälern. Aber er muss halt stellung beziehen damit kommende Kunden wissen woran sie sind.
Ich weis das er daran arbeiten wird wenn es einen machbaren Weg für ihn gibt. War ja bissher immer so. Also ... weiter so @GernotFrisch
MfG Turgut Temucin alias TFT
GLOBAL Var AS Tdll_loader // Tdll_loader ist ein Interner Type von GLB
Var = loaddll("test.dll") // Loaddll ist eine function vom Type Tdll_loader
//und gibt auch diesen TYPE zurück
PRINT Var.name$, 10,10 //Ausgabe vom dll Namen
PRINT Var.anzahl, 10,10 //Ausgabe der anzahl der vorhandenen Funktionen
PRINT Var.func_name$[0], 10,10 //Ausgabe des Functionsnamen mit benötigten Argumenten und rückgabe
//Z.B: erste ist er name, letzte die rückgabe, mitendrin die Argumente
//math, int,int,float,float
//Functions aufruf
test = Var.run("name der Function",Argument1,Arg2)// Aufruf der function
PRINT test,10,100
o.O
ich mach nicht soviel mit dll, sorry :)
Das geht so nicht, weil die DLL nicht weiß welche Argumente eine Funktion hat - nur den Namen.
Noch mal eine bitte an Gernot:
Mach doch mal ein Beispiel wie man eine Simple Function exportiert, und dann die DLL lädt... aber bitte ganz simpel.
Kann ja nur eine Addition beinhalten oder so, reicht ja.... *LIEBGUCK* :D
Schließe mich Schranzi an! Bin auch neugierig, wie's funktioniert!!!
Das ist noch richtig Beta. Ich mach ganz klar ein Beispiel, wenn's läuft.
Klingt super! =)
Hi ....
um das Problem mit den verschiedenen Parametern für DLL Funktionen zu umgehen. Könnte man doch eine Definitions Datei einführen. Diese teile hiessen früher *.LIB" und enthielten die Aufruf konventionen der Funktion. Beim Kompiliren muss dann nur geprüft werden ob die Definition mit dem Programm Code überein stimmt . Der Programmierer ist dann für die Definition zuständig, Und ungültige aufrufe werden schon beim Compilieren abgefangen. Das funktioniert aus mit Standart DLL APIS.
Gruss TFT
Hi! Gibt es (nur so nebenbei) nochmal eine Möglichkeit ein Update manuell runter zu laden? Habe noch immer keinen mobilen Internetzugang... =(
Sauge mir nämlich gerade v5 für den Laptop runter...
GLG
W.
Die (deutschen) Updates liegen unter http://www.glbasic.com/~GLBasic5_update.zip
Die Versionsnummer in http://www.glbasic.com/~GLBasic5_update.txt
bittscheen
Perfekt! Danke! *freu*
na gerne doch, zur Verfügung stellte dies unser lieber Gernot.