Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
heute hab ich es soweit hinbekommen, dass der Fehlercode 22 nicht mehr auftritt. Allerdings kommt er nun mit dem Feature nicht klar. Das erzeugt dann den Fehler 31. Laut Definition in der Headerdatei ist die Feature_id als U32 deklariert. Wenn ich das in LV einstelle, kommt jedoch eine Fehlermeldung (31) raus.
Die Feature_id ist bei mir numerisch U32 und wird als Zeiger übergeben. Laut Definition sollte hier direkt der Wert übergeben werden, das führt jedoch bei mir zum Absturz von LV.
1. Ich kenne mich besser aus mit der Vorgängerversion, HASP HL, aber ich denke mal, allzuviel wird sich wohl nicht bei HASP SRM geändert haben.
2. die feature id übergibst du einfach nur als Wert, nicht als Pointer, vom Typ U32. Da braucht die Funktion nur den Wert. Zum Aufbau der feature id, schau dir mal die Toolbox im Vendor Center an und probier einfach mal alle Optionen, schon weist du, wie die vendor id aufgebaut wird.
3. Rückgabe Handle als Pointer to U32! Das &-Zeichen bei der C-Definition zeigt an, dass dieser Wert als Pointer übergeben wird.
4. Aufruf als StdCall isse OK.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
offensichtlich gibt es doch größere Unterschiede zwischen der Toolbox von HASP HL und HASP SRM.
Anbei ein Screenshot von dem, was ich in der Toolbox sehe...
Kein Wunder, dass ich nicht so recht wusste, was du mit der feature_id meintest. Ich bekomme das ja nicht angezeigt. Allerdings ist die von dir angegebene ID ja ein HEX-Wert. Wenn ich den umwandle, dann hab ich auch wieder ne Null. (In LabVIEW wäre das ja ein HEX-String, welchen die Funktion nicht akzeptiert).
Irgendwie bekomme ich jetzt auch nicht mehr den Code 31, obwohl ich nichts geändert habe.... *kopfkratz*
Jetzt zeigt er wieder die 22 an (wrong vendor code).
Ich lad mir mal die HASP HL Software runter, vielleicht bringt mich das weiter...
06.12.2007, 10:05 (Dieser Beitrag wurde zuletzt bearbeitet: 06.12.2007 10:08 von rolfk.)
heute hab ich es soweit hinbekommen, dass der Fehlercode 22 nicht mehr auftritt. Allerdings kommt er nun mit dem Feature nicht klar. Das erzeugt dann den Fehler 31. Laut Definition in der Headerdatei ist die Feature_id als U32 deklariert. Wenn ich das in LV einstelle, kommt jedoch eine Fehlermeldung (31) raus.
Die Feature_id ist bei mir numerisch U32 und wird als Zeiger übergeben. Laut Definition sollte hier direkt der Wert übergeben werden, das führt jedoch bei mir zum Absturz von LV.
Anbei mal 2 Screenshots zur Verdeutlichung...
Also die Konfiguration Deines DLL Knotens ist sicher falsch. So wie Jens schon gesagt hat musst Du die Feature ID NICHT als Pointer übergeben.
Der String sollte OK sein aber das Handle ist wieder falsch. Scheinbar hast Du einfach ein & vor den Variablennamen gestellt. Aber das macht diesen Parameter keinen Pointer. Anstelle davon musst Du diesen Parameter als U32 definieren und als Pointer. Das & kann wegbleiben, tut doch nichts.
Dein Funktionsprototyp unten im DLL Knotendialog sollte danach so aussehen:
unsigned long hasp_login(unsigned long feature, unsigned char *vendor_code, unsigned long *handle);
Bei der Deklaration einer Variablen in C muss man * voranstellen um es als Pointer zu deklarieren aber beim Aufrufen einer Funktion muss man & an den Variablennamen stellen um den Pointer auf die Variable zu übergeben.
Der Code in Deiner HASP Toolbox ist der Aufrufcode deshalb das &. Die Funktionsdeklaration ist aber irgendwo in einer haspxx.h oder ähnlichen Datei zu finden.
Was die Feature ID betrifft, nichts Hex String oder so son dern einfach eine vorzeichenlose 32 bit numerische Konstante. 0xffff0000 wie ich es irgendwo gesehen habe kannst Du dann ganz einfach eingeben indem Du mit der rechten Maustaste auf diese Konstante klickst und Visible Items->Radix (weiss die in LabVIEW verwendete deutsche Übersetzung nicht) anwählst. Danach auf das erscheinende d am linken Rand klicken und anstelle von Dezimal Hex wählen. Das d verändert in x. Nun kannst Du ffff0000 direkt einführen.
Wen HASP_DEFAULT_FID etwas anderes ist als 0xFFFF0000 dann musst Du natürlich die entstprechende Konstante verwenden. Welchen Wert das sein muss kannst Du der zuvor angesprochenen haspxx.h oder ähnlichem Headerdatei entnehmen.
Der Fehler war das "&" vor dem handle und das Format der feature_id. Die Sache mit dem Umstellen auf HEX bei numerischen Konstanten wusste ich bis dato nicht!
Soweit so gut, Login und Logout funktionieren jetzt scheinbar richtig.
Allerdings hab ich hier noch Probleme mit der hasp_get_info, bzw. genauer gesagt mit dem Ergebnis dieser Funktion.
Get Info wird an sich fehlerfrei ausgeführt. Das Ergebnis dieser "Informationsanfrage" wird jedoch nicht direkt zurückgegeben. Vielmehr muss man der Funktion einen Pointer mitgeben, der nach der Ausführung auf das Ergebnis zeigt.
So, wie ich das verstanden habe, müsste sich das Ergebnis der Funktion über den info-Pointer auslesen lassen (Funktion gibt die Adresse von *info zurück). Ich hab allerdings keinen Schimmer, wie ich das in LabVIEW machen soll. Die Funktion an sich scheint richtig zu laufen. Ich weiss momentan nur nicht, wie ich über den Pointer, der ja auf die Informationen zeigt, an den Inhalt selbst rankommen soll.
Ich hoffe, das war nicht zu konfus...
Vielleicht kann mir ja jemand von euch helfen!
P.S.: Die Suchfunktion förderte schon einiges zu Tage, ich hab auch den "MoveBlock" ausprobiert, aber das klappte irgendwie auch nicht.
07.12.2007, 15:18 (Dieser Beitrag wurde zuletzt bearbeitet: 07.12.2007 15:18 von jg.)
Autsch, das ist mit der (LabVIEW-mässig gesehen) übelste Funktionsaufruf, da muss ich auch erst mal nachschauen, meine aber, das habe ich auch nur per MoveBlock hingekriegt. Du bist also schon auf dem richtigen Weg.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
habe mir gerade noch mal den HASP_SRM_Guide angeschaut und meine Unterlagen über die ähnliche Funktion get_sessioninfo.
Also: scope und format übergibst du am besten als String (C String Pointer), vendor code wie schon gehabt bei der Login-Funktion. Jetzt noch zum char **info, um an die Startadresse zu kommen, habe ich in LV diesen Parameter als Array (1-dimensional), Datentyp U32, Array Format "Array Data Pointer" definiert.
Dies dann sicherheitshalber mit einem 1D-Array der Größe 1 initialisiert, der Ausgang ist dann also ein 1D-Array der Größe 1, wobei dieser eine Wert jetzt die Startadresse der Blockes info enthält, sprich dies ist also jetzt die Startadresse des Bereiches, den du mit der von dir schon gefundenen Funktion "MoveBlock" auslesen kannst.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
habe mir gerade noch mal den HASP_SRM_Guide angeschaut und meine Unterlagen über die ähnliche Funktion get_sessioninfo.
Also: scope und format übergibst du am besten als String (C String Pointer), vendor code wie schon gehabt bei der Login-Funktion. Jetzt noch zum char **info, um an die Startadresse zu kommen, habe ich in LV diesen Parameter als Array (1-dimensional), Datentyp U32, Array Format "Array Data Pointer" definiert.
Dies dann sicherheitshalber mit einem 1D-Array der Größe 1 initialisiert, der Ausgang ist dann also ein 1D-Array der Größe 1, wobei dieser eine Wert jetzt die Startadresse der Blockes info enthält, sprich dies ist also jetzt die Startadresse des Bereiches, den du mit der von dir schon gefundenen Funktion "MoveBlock" auslesen kannst.
MfG, Jens
Anstelle eines Arrays von einem Element Länge kannst Du hier auch einfach einen uInt32 gebrauchen, den Du als Pass als Pointer konfigurierst. So wie Du das hier beschreibst wird dann für diesen Pointer auch in der Funktion Speicher alloziert. Dann sollte die Library auch eine Funktion exportieren um diesen Speicherbereich später wieder zu deallozieren. Ansonsten baust Du ein Memoryleak.
' schrieb:Anstelle eines Arrays von einem Element Länge kannst Du hier auch einfach einen uInt32 gebrauchen, den Du als Pass als Pointer konfigurierst. So wie Du das hier beschreibst wird dann für diesen Pointer auch in der Funktion Speicher alloziert. Dann sollte die Library auch eine Funktion exportieren um diesen Speicherbereich später wieder zu deallozieren. Ansonsten baust Du ein Memoryleak.
Rolf Kalbermatter
Danke für den Tip, werde ich auch mal probieren. HASP-API bietet aber auch eine Funktion, um Speicher wieder freizugeben, die ich auch schön brav anwende.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
