Freebasic "zstring ptr" was in Purebasic?

[real]

Update

Code: Alles auswählen

PrototypeC.l ProtonLoadTexture(*filename)

in Verbindung mit

Code: Alles auswählen

texture01.l = nLoadTexture(@"media/mur_Ambiant.jpg")

bringen ebenfalls einen Fehler beim Speicherzugriff...

Hatte mich schon gewundert, dass hinter filename ein .s stand, denn ein Pointer zeigt ja lediglich auf eine Adresse. Der Typ ist ja in dem Fall egal...

Was macht dieses zstring ptr in Freebasic so einzigartig, dass ich den nicht auch unter Purebasic hinbekomme? Wenn ich eine DLL-Funktion nutzen möchte MUSS ich doch einen String über einen Pointer übergeben. Und das sollte PB doch mit einem

Code: Alles auswählen

PrototypeC.l ProtonLoadTexture(filename.s)

machen, oder? Hat jemand eine Idee, wie ich debuggen kann, was der DLL tatsächlich übergeben wird?

[helpy]

Könnte es sein, dass die DLL den String (Dateiname) in ASCII will und Du kompilierst das PB Programm mit der Unicode-Option? Wenn Du dann einen Pointer auf den Unicode-String an die DLL übergibst, passt das natürlich nicht.

Dann könnte folgendes helfen:

Code: Alles auswählen

PrototypeC.l ProtonLoadTexture(filename.p-ascii)
Global nLoadTexture.ProtonLoadTexture = GetFunction(1,"LoadTexture")
texture01.l = nLoadTexture("media/mur_Ambiant.jpg")

Mit dem Pseudotype p-ascii ... gebe ich dem PB Compiler an, dass er vorher den String (falls nötig) nach ASCII wandelt und dann den Pointer auf den ASCII-String an die DLL-Funktion übergibt.

Außerdem würde ich noch überprüfen, ob der relative Pfad "media/mur_Ambiant.jpg" von der DLL richtig interpretiert wird!

cu, helpy

[helpy]

Un hier noch ein paar Infos zu zstring:

=> http://www.freebasic-portal.de/index.ph ... opic&id=60

[real]

Ich glaube mittlerweile, dass die Stringübergabe an sich nicht einmal das Problem ist. Scheinbar (so deute ich OllyDbg) kann mein PB-Programm die DLL-Routine garnicht aufrufen. DAHER scheint der fehlerhafte Speicherzugriff zu stammen.

In dem Freebasic-Include steht oben eine Zeile

Code: Alles auswählen

#incbin "Ninfa3D"

, die den Unterschied zu meinem Include zu machen scheint, wo ich die DLL mit LoadLibrary öffne und dann mit GetFunction die Funktionszeiger erhalte.

[helpy]

Überprüf doch, ob GetFunction() wirklich einen Funktionszeiger zurückgibt:

==> Debug GetFunction(1,"LoadTexture")

Wenn da null zurückkommt, findet er die Funktion nicht!

[real]

Die Funktion hat er gefunden. Und ich den Fehler: meine Dummheit war's. Ich wollte den Beispielquellcode auf'hübschen' und hab das entsprechende Include genutzt, bevor Ninfa3D selbst initialisiert war. Daher der Speicherfehler...

Ich hatte einen Parser geschrieben, der das Freebasic-Include selbstständig in ein Purebasic-Include umwandelt. Um die Funktionalität des Parsers zu testen wollte ich natürlich das Purebasic-Include testen, also hab ich 'auf die Schnelle' den Freebasic-Quellcode eines Beispiels noch manuell in Purebasic umgewandelt.

VIELEN DANK FÜR EURE UNTERSTÜTZUNG...

Das Freebasic-Beispiel "Body - Water" funktioniert schonmal:

[ralle]

>> Man kann lediglich eine Strukture angeben um einen strukturierten Pointer zu erhalten.

also in dem Fall garnix, weil Structs als Parameter nicht akzeptiert werden.

Selbstverständlich werden Pointer auf Structs als Parameter akzeptiert.

Code: Alles auswählen

Procedure test(*varname.strucname)

So was benutze ich andauernd, um z.B. mehrere Rückgabewerte aus einer Funktion zu erhalten.

MfG
Ralph[/code]

[Kaeru Gaman]

>> Man kann lediglich eine Strukture angeben um einen strukturierten Pointer zu erhalten.

also in dem Fall garnix, weil Structs als Parameter nicht akzeptiert werden.

Selbstverständlich werden Pointer auf Structs als Parameter akzeptiert.

Code: Alles auswählen

Procedure test(*varname.strucname)

So was benutze ich andauernd, um z.B. mehrere Rückgabewerte aus einer Funktion zu erhalten.

MfG
Ralph[/code]

lies meinen Satz bitte noch mal langsam...