Das deutsche QBasic- und FreeBASIC-Forum

[Windowsmuffel]

Hallo Leute,

ich möchte einfach ein Array an eine dll übergeben.

Habe alles ordnungsgemäss declariert:

[raph ael]

Hi,

[Flo]

oder vlt statt array einfach die adresse von array(0) (oder 1) übergeben?
kA, ich spiel eig nur in c mit pointern rum und da geht das

aber, von wegen facedetection: wie soll das gehen? ein gesicht einigen abgespeicherten zuordnen? oder "einfach nur" die verschiedenen gesichtspartieen voneinander trennen
interessiert wäre ich ja *gg*
_________________
MFG
Flo

Satoru Iwata: Wer Spaß am Spielen hat, fragt nicht nach Grafik.

zum korrekten Verstaendnis meiner Beitraege ist die regelmaessige Wartung des Ironiedetektors unerlaesslich.

[ThePuppetMaster]

Wenn du so declarierst:
[quote="Windowsmuffel"]

[Windowsmuffel]

Hallo alle zusammen,

leider funktioniert alles nicht

Bei:

[ThePuppetMaster]

Wups .. das hab ich ja garnicht gesehen ... das Shared kannst du weg lassen, genauso wie das Dim.

[Windowsmuffel]

Hi TPM,

die Function "Testfunktion" befindet sich in einer externen dll.

Deshalb auch dieses:

[volta]

Was ist daran so schwierig?
Testdll.bas => Testdll.dll

[Windowsmuffel]

Hallo,

das Problem dabei ist das die dll in der Funktion eine Fremdll ist und ich leider daran nichts mehr ändern kann. Alle Funktionen in der dll funktionieren auch aus FB heraus - nur die eine Funktion mit dem Array nicht.
In VB kann ich die Funktion allerding ansprechen und es funzt.
Nur müsste ich dann Arrays zwischen FB und VB hin und herschieben was ich nicht gerade als einen tollen Programmierstil empfinde...
Ergo sollte die dll als solchige auch OK sein.


mfg
Windowsmuffel

[volta]

[Windowsmuffel]

Muss eigendlich ein ganz simpler Fehler meinerseits sein ...

Deklaration VB

[volta]

Da werde ich auch nicht schlau raus

nur eine leere Dimensionierung dim imgo() as byte
ein Funktionsaufruf der anscheinend kein Array angibt xa = testfunk(imgo)
obwohl die Declaration ein Array verlangt?
So kenn ich VB garnicht
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater.

[AndT]

Ich habs mal so nebenbei hingetextet (nicht gestestet!!)
arreytest.bas:(DLL)

[Joseph]

Hallo,

mögliche Ursachen für Dein Problem:
1. Sind die handles auf die DLL und die Funktion innerhalb der DLL gültige, von Null verschiedene Werte? Wenn ja, hat schon mal das Laden geklappt, ansonsten scheint hier das erste Problem zu liegen. Lass Dir doch einfach mal die beiden handles anzeigen, um das zu überprüfen.
2. Stimmen die Datentypen? Du definierst den Rückgabewert Deiner Funktion als LONG. Dabei ist aber zu beachten, dass in FB der Datentyp LONG eine 64-bit-Ganzzahl bedeutet und INTEGER eine 32-bit-Ganzzahl. Ich hab gerade bezüglich Datentypen in VB gestöbert und laut der Übersicht ist in VB LONG eine 32-bit Ganzzahl. Wenn Deine Funktion eine 32-bit-Ganzzahl als Rückgabewert erfordert, wäre das in FB somit INTEGER und in VB LONG.

Hoffe, ich konnte bei der Lösung weiterhelfen.

[Windowsmuffel]

Hallo Joseph,

das ist alles geprüft und soltte stimmen da ich aus der dll auch andere Funktionen einwandfrei nutzen kann.

Mittlerweile bin ich der Lösung schon einen Schritt näher gekommen.

Ich kann diese eine Funktion der dll weder innerhalb einer eigenen Funktion noch sonst irgendwie. nutzen - gibt die verschiedensten Fehlermeldungen bis hin zum Absturz.

Nun glaubte ich langsam nicht mehr an einen Programmierfehler und habe die Sache auf einem anderen PC getestet - und siehe da: es geht!

Allerdings nur außerhalb einer Funktion

Der einzige grobe Unterschied der beiden PC´s ist XP und der Prozessor. Mit Prof. und Dualcore geht gar nichts mit Home und Celeron geht es wenigstens außerhalb einer Funktion.

Es könnte allerdings dann auch an der (fremd)dll liegen....

Beste Grüße an Alle
Windowsmuffel

[Joseph]

Hallo Windowsmuffel!

Auch wenn die Chancen auf Erfolg gering sind, angesichts der offensichtlichen Probleme mit dem OS/cores, könntest Du noch folgendes probieren:
Wenn es vom Programmablauf her möglich ist, könntest Du versuchen, diese eine Funktion aus der DLL Deinem Programm statisch hinzuzubinden, also so wie bei jeder gewöhnlichen statischen Lib. Das kannst Du in FB folgendermaßen bewerkstelligen:

1. Eine Kopie der DLL anlegen.
2. Die Dateiendung der Kopie von .dll in .a umbenennen (z.B. mydll.dll -> mydll.a).
3. In Deinem Programm die so erzeugte statische Lib mit #inclib einbinden, dabei die Dateiendung weglassen, z.B. so: #inclib "mydll".
4. Die Funktion ganz normal deklarieren, z.B. so: declare function testfunk(array() as byte) as long.

Wie gesagt, ob's klappt ist fraglich, wenn das Problem innerhalb der DLL liegt. Aber es sollte zumindest bei "geeignetem" OS möglich sein, die Funktion überall in Deinem Programm anzusprechen und vielleicht klappt's damit ja doch, auch bei XP Prof. bzw. multi-cores.

[Windowsmuffel]

Hallo Joseph,

vielen Dank für Deinen Tip - habe gar nicht gewüßt das es so herum auch funktioniern kann

Es hat leider auch, außer einer (neuen?) Erkenntniss, nichts gebracht - nähmich: man darf einfach nicht so faul sein und sich nur auf der früchte anderer Arbeit ausruhen wollen.

In der Zeit die ich nun mit diesem "Problemchen" verbracht habe hätte ich mich auch in die Thematik einarbeiten und eine eigene dll schreiben können


Aus Erfahrung wird man klug....

Beste Grüße
Windowsmuffel

[volta]

Hi @Joseph,
das

[Joseph]

@Volta,

doch, das Umbenennen der DLL in eine .a-Datei und das Einbinden mit #inclib hat bei mir funktioniert. Ich hab das mit einer eigenen, mit FB erstellten DLL ausgetestet. Diese enthält mathematische Funktionen und ich konnte beim Testlauf korrekte Rückgabewerte erhalten, die auch in der normalen Variante als DLL herausgekommen wären. Im kleinen Testprogramm waren auch keinerlei handles auf die eigentliche DLL enthalten und es gab beim Kompilieren keine Fehler oder Warnungen, also völlig ausgeschlossen, dass hier doch ein Zugriff auf die eigentliche DLL erfolgte. Allerdings habe ich dabei FB0.16 verwendet, auch die DLL wurde mit FB0.16 erstellt, unter 0.17 oder 0.18 hab ich's nicht getestet (sorry). Möglich also, dass das unter 0.16 zwar funktioniert (obwohl es nicht funktionieren sollte), aber nicht mehr in späteren Versionen. Werde das ganze nochmals gründlich auch mit FB0.17 und FB0.18 austesten. Wenn das dort nicht funktioniert, dann hat FB0.16 (vielleicht auch die früheren Versionen) einen Bug, der unter Umständen sogar nützlich sein könnte.

[Joseph]

Hallo nochmal,

möchte Euch über den Versuch, eine dll statisch einzubinden informieren und habe dabei eine wahrscheinlich noch undokumentierte (Fehl-)Funktion von FB entdeckt:
Zunächst das Wichtigste: Die Variante mit dem Umbenennen der dll in eine .a-Datei läuft tatsächlich nicht. Der Grund warum es bei meinem ersten Versuch scheinbar geklappt hat war der, dass sich sowohl die ursprüngliche dll als auch die .a-Datei, aber auch die .bas-Datei im selben Verzeichnis befanden. Nun habe ich folgendes herausgefunden: Wenn sich die .bas-Datei aber auch die .dll im selben Verzeichnis befinden und die .a-Datei einen für eine statische lib ungültigen header hat oder nicht vorhanden ist, ist es möglich, die dll mit #inclib einzubinden, aber nicht als statische lib sondern als ganz normale dll, d.h. das Programm läuft ohne die dll nicht, und das obwohl #inclib dafür gar nicht vorgesehen ist und gar keine handles definiert werden müssen! Dies konnte ich überprüfen, indem ich die exe-Datei in einen anderen Ordner verschoben habe, und starten wollte. Sofort kam die übliche Fehlermeldung, dass die dll nicht gefunden wurde. Habe die dll dann in denselben Ordner wie die exe verschoben und alles lief problemlos. FB hat also mit #inclib keine rein statische exe erzeugt, sondern eine exe, die zur Laufzeit eine dll benötigt. Was ich ebenfalls herausgefunden habe ist, dass das Kompilieren in so einem Fall nur funktioniert, wenn sich die .bas-Datei und die dll im selben Ordner befinden, eine zusätzliche Pfadangabe funktioniert nicht.
Dies habe ich mit FB0.16 als auch FB0.18 geprüft, wobei die dll mit FB0.16 erstellt wurde.

Offenbar geht FB so vor: Wenn mit #inclib eine statische lib eingebunden werden soll, versucht FB die .a-Datei zu öffnen. Wenn der header der .a-Datei nicht passt oder die .a-Datei gar nicht vorhanden ist, sucht FB nach einer dll mit dem Namen. Wenn diese gefunden wurde, wird diese als normale dll eingebunden und muss zur Laufzeit des Programms vorhanden sein, was so aber gar nicht für #inclib vorgesehen ist.

Dies führt aber nun zu der interessanten Option, dass es offenbar möglich ist, wenn auch nicht beabsichtigt, #inclib unter den genannten Bedingungen auch zum Einbinden einer dll zu nutzen, ohne sich mit den ganzen handles herumschlagen zu müssen. Auch das auf den ersten Blick umständlich erscheinende Dimensionieren der dll-Subs/Funktionen mit z.B. dim as function... und dylibsymbol kann dabei entfallen. Wäre jetzt nur noch interessant, ob das auch zuverlässig funktioniert. Natürlich gibt es bei der Variante keine Möglichkeit, die dll bei Nichtbedarf mit dylibfree wieder aus dem Speicher zu entfernen.