PB-Crash bei ProcedureReturn?

[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

[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.

[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

[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.

[Robert Wünsche]

Bestimmt muss man die anderen befehle mit einem aktivierungsbefehl aktivieren.
Oder man muss die dll prodzeduren irgentwie direkt anspringen.

[GPI]

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.

[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) .

[Danilo]

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.

[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

[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.