Seite 1 von 2
PB-Crash bei ProcedureReturn?
Verfasst: 31.10.2004 17:54
von Kiffi
Hallo,
ich bin ein wenig ratlos. Ich versuche, ein paar Anweisungen in Procedures
auszulagen und scheitere scheinbar an den einfachsten Aufgaben.
Ziel meines Code ist es, SQLite3-Funktionalitäten in mein Program
einzubinden. Die Procedure SQLite3_Init() funktioniert tadellos. Hiernach
versuche ich eine Datenbank zu erstellen (SQLite3_OpenDatabase(sDB.s))
hierzu nehme ich folgenden Aufruf:
Code: Alles auswählen
If CallFunctionFast(sqlite3_open, "test.db", @sqlite3_dbHandle) = #SQLITE_OK
Debug sqlite3_dbHandle
Else
Debug 0
EndIf
Das funktioniert auch ohne Probleme. Packe ich obige Zeilen in eine
Procedure, dann schmiert mir PB in der Zeile ProcedureReturn 1 ab (siehe
unten).
Wer weiss Rat?
Danke im voraus & Grüße ... Kiffi
Code: Alles auswählen
#SQLITE_OK = 0 ; Successful Result
Global sqlite3_open.l
Global sqlite3_dbHandle.l
Procedure.l SQLite3_Init()
If OpenLibrary(255,"sqlite3.dll")
sqlite3_open = IsFunction(255, "sqlite3_open")
ProcedureReturn 1
Else
ProcedureReturn 0
EndIf
EndProcedure
Procedure.l SQLite3_OpenDatabase(sDataBase.s)
If CallFunctionFast(sqlite3_open, sDataBase, @sqlite3_dbHandle) = #SQLITE_OK
Debug sqlite3_dbHandle
ProcedureReturn 1 ; Hier knallt's!
Else
ProcedureReturn 0
EndIf
EndProcedure
DeleteFile("test.db")
If SQLite3_Init()
CallDebugger
; Das funktioniert
If CallFunctionFast(sqlite3_open, "test.db", @sqlite3_dbHandle) = #SQLITE_OK
Debug sqlite3_dbHandle
Else
Debug 0
EndIf
MessageRequester("","!")
; Das nicht
If SQLite3_OpenDatabase("test.db")
Debug sqlite3_dbHandle
EndIf
EndIf
Verfasst: 31.10.2004 18:27
von GPI
Probier mal CallCFunctionFast(). Es gibt zwei arten von DLLs und der Absturz ist das eindeutige Zeichen, das es sich um eine C-DLL handelt und keine Standard-DLL.
Verfasst: 31.10.2004 19:05
von Kiffi
> Probier mal CallCFunctionFast().
Potztausend! Das scheint es gewesen zu sein.
Ich dachte, der Fehler läge bei ProcedureReturn, weil es erst da kracht. Merkwürdig...
Vielen Dank für Deine Hilfe!
Grüße ... Kiffi
Verfasst: 31.10.2004 19:08
von Falko
@GPI
Und was hat GFA-Basic (16Bit) für eine DLL?
Da funzt beides irgendwie net!
Habe noch nicht rausgefunden, wie man diese in PB ausführen kann.
Oder weis jemand, wie man diese ausführen kann?
MfG Falko
> [Edit] Anscheinend benutzt GFA für DLL noch eine 3. Variante,
> was die Fehlermeldung mit Abbildfehler und dies ...ist keine > gültige Windows DLL... ausgibt.
Verfasst: 31.10.2004 20:13
von Robert Wünsche
Bestimmt muss man die anderen befehle mit einem aktivierungsbefehl aktivieren.
Oder man muss die dll prodzeduren irgentwie direkt anspringen.
Verfasst: 31.10.2004 20:43
von GPI
Kiffi hat geschrieben:Ich dachte, der Fehler läge bei ProcedureReturn, weil es erst da kracht. Merkwürdig...
Leicht zu erklären:
Wenn man eine Subroutine (in den fall halt die DLL) aufruft, wird die Rücksprungadresse auch auf den Stack abgelegt.
Die Parameter der Subroutine sind auch im Stack. Jetzt gibt es zwei möglichkeiten:
Die Parameter werden von der Subroutine von Stack entfernt oder nicht.
Bei ProcedureReturn ist gerade ein Parameter und nicht der Rücksprungadresse in Stack aktiv, weil CallFunktionFast nicht richtig aufgeräumt hat.
So grob mußt du dir das vorstellen.
Verfasst: 31.10.2004 21:13
von Rings
Stimmt GPI !
Falko: du wirst nie ne 16 Bit dll unter 32 Bit ansprechen können.Das geht halt net (höchstens durch irgendwelche hacks, aber ich kenne keine) .
Verfasst: 31.10.2004 22:54
von Danilo
Rings hat geschrieben:Falko: du wirst nie ne 16 Bit dll unter 32 Bit ansprechen können.Das geht halt net (höchstens durch irgendwelche hacks, aber ich kenne keine) .
Ich glaube mich daran zu erinnern das ich darüber vor vielen
Jahren (bei der Umstellung von Win3.1 auf Win95) mal etwas
in MSDN gelesen habe. Und zwar das es da einen offiziellen,
von MS dokumentierten, Weg gab.
Diese Umstellungen haben die meisten Coder allerdings vor
8 - 9 Jahren vollzogen (auf Win95), weshalb es sein kann
das es auf modernen NT-Systemen nicht mehr geht.
Auch wenn es im Moment modern zu sein scheint wieder DOS
und Konsorten rauszukramen und in QB etc. zu coden, würde
ich doch sagen Du solltest dieses uralte(!) Zeug einfach vergessen.
Mit einer modernen Programmierumgebung kannst Du
sicher auch alles machen was Du mit Gfa vor 10 Jahren
schon gemacht hast.
Ansonsten einfach einen Emulator installieren und dazu
dann DOS oder Win3.1 wieder drauf.
Kannst Dir ja mal
QEMU und
QEMU für Windows anschauen.
Verfasst: 31.10.2004 23:11
von Falko
Erstmal danke @Rings und @Danilo
Diese GFABasic für Windows läuft bis WinMe. Also ist das doch keine DOS-Compiler. Für DOS hatte ich mir damals auch ein eigenes GFA-Basic gekauft. Die Letzte Version die ich mir als Upgrade erworben hatte, war GB32 von GFA und diese unterstützt zwar Windows (läuft mit einigen Ausnahmen auch noch unter WindowsXP), aber damit kann man leider keine
DLL's erzeugen. Statt dessen hat man damit die Möglichkeit OCXes zu erstellen. Nur damit habe ich mich bis jetzt noch nicht mit beschäftigt.
Schade, das diese dll's nicht unter PB funktionieren. Ich hätte gehofft, damit noch was in Sachen in PB ergänzen zu können. Zwar habe ich noch eine andere Möglichkeit die PowerDLLCompiler heißt. Nur ist eben alles in Englisch und nicht so leicht verständlich wie PB.
Ich glaube auch, das ich GFA-Basic so langsam aus meinem Kopf kriegen
muß.
MfG Falko
Verfasst: 31.10.2004 23:37
von Danilo
Falko, DU sagtest oben das die Gfa-DLL 16-bit ist, also kann
es nicht für Win32 sein.
Deshalb meinte ich bei Dir speziell auch mehr Win3.1, also
das 16-bit-Windows aus der Steinzeit.
Diese 16-bit-Programme liefen aber auch weiterhin auf Win9x.
Für die Verwendung von Win16-Zeug unter Win32 kannste ja
mal ins MSDN und in die Win32.hlp sehen (haste die schonmal
komplett durchgeblättert, von vorn bis hinten?).
OCX sind aber eig. auch nur 32-bit-DLLs, die man ganz normal
mit OpenLibrary ansprechen kann (wenn kein OOP-Zeugs drin
ist, sondern normale Funktionen).
Zieh mal die OCX auf den
PE-Viewer (Drag & Drop
) und schau
Dir an was bei den Exports steht.