INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

DLL Import externe Struktur in Header bekommen



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!

26.09.2016, 17:37
Beitrag #11

hansi9990 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 180
Registriert seit: Mar 2015

2019
2014
DE

96xxx
Deutschland
Wink RE: DLL Import externe Struktur in Header bekommen
Willst du etwa am Christlichen Glauben zweifeln? Angel_not Big Grin
Scherz beiseite, ich meinte damit das ich evtl. gerade an einer Stelle den Ausführung abgebrochen hätte wo der Speicher angelegt aber nicht mehr aufgeräumt wurde und mir das dann "zufällig" immer nur unter Windows 7 passiert ist, und nicht das der PC eigenständig und zufällig reagierte. Wink
Aber das waren ja alles nur vermutungen.

Ich habe diese VI's unter Windows 10 schon seit mehreren Tagen ohne Crash am laufen, ausgenommen bei einem mal, an dem ich versehentlich einen Speicherbereich von 0 einstellte, darum kam mir auch der Gedanke das es etwas mit der Größe des Speicherbrereichs zu tun haben muss. Heute hatte cih auch unter Windows 7 keinen einzigen Crash.

Seit ich dort das Bedienelement gegen eine Konstante austauschte, hatte ich diese Abstürze nicht mehr, zuhause hatte ich das Bedienelemet von 8288 auf 8296Byte erhöht und vergessen diesen Wert als Standard festzulegen, als ich das VI am Windows 7 PC in der Firma startete, stand wieder 8288Byte im Bedienelement.
Ich vermute das dies der Grund für die Abstürze war, die auch nur selten auftraten und der Hinweis von dir war somit wohl auch genau richtig.
Mit einer Konstante kann dieser Fehler nicht mehr passieren.

Nochmal vielen Dank für deine Hilfe Smile
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
27.09.2016, 19:29
Beitrag #12

hansi9990 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 180
Registriert seit: Mar 2015

2019
2014
DE

96xxx
Deutschland
RE: DLL Import externe Struktur in Header bekommen
PS: Ich hatte Probleme mit dem lesen des Buffer im HID Device, der Knoten wartete/hängte immer bis sich im Buffer etwas änderte (ergo, erst wenn ein Gerät etwas sendete, wenn mein Empfänger keine Packete erhielt dann hing es beim Read Buffer). Jetzt habe ich mal versucht den Speicherbereich mit den LabView Manager Funktionen (DSNewPClr und DSDisposePtr) anzulegen und siehe da es hängt nicht mehr und liest sauber den Buffer des HID Device.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
27.09.2016, 20:52
Beitrag #13

rolfk Offline
LVF-Guru
*****


Beiträge: 2.302
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
RE: DLL Import externe Struktur in Header bekommen
(27.09.2016 19:29 )hansi9990 schrieb:  PS: Ich hatte Probleme mit dem lesen des Buffer im HID Device, der Knoten wartete/hängte immer bis sich im Buffer etwas änderte (ergo, erst wenn ein Gerät etwas sendete, wenn mein Empfänger keine Packete erhielt dann hing es beim Read Buffer). Jetzt habe ich mal versucht den Speicherbereich mit den LabView Manager Funktionen (DSNewPClr und DSDisposePtr) anzulegen und siehe da es hängt nicht mehr und liest sauber den Buffer des HID Device.

Tja, meine Vermutung hat mit them Clr in DSNewPClr() zu tun. Diese Funktion alloziert then Speicher und initialisiert ihn komplett mit 0 (Clr = Clear). Die CoTaskMemAlloc() Funktion löscht den Speicher nicht, also hat er irgendwelche Randomwerte. Nun hätte ich so gedacht, dass die Funktion HID_Init() ja irgendetwas sinnvolles tun sollte, wenn sie schon nicht den Speicherbereich selber anlegt (Du rufst die doch auf so wie es im Headerfile auch steht?)

Aber scheinbar war auch das eine vergebliche Hoffnung! Angry

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
28.09.2016, 19:51 (Dieser Beitrag wurde zuletzt bearbeitet: 28.09.2016 19:52 von hansi9990.)
Beitrag #14

hansi9990 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 180
Registriert seit: Mar 2015

2019
2014
DE

96xxx
Deutschland
RE: DLL Import externe Struktur in Header bekommen
Ja, ich habe die beiden Knoten ole32.dll CoTaskMemAlloc() und SebaHID.dll HID_Init() in einem VI zusammengefasst, im Header war der Init so definiert

Code:
/**
\fn      VOID HID_Init(struct strHidDevice* pstrHidDevice);

\brief   Init structure with default values.
         - It is important to call HID_Init before calling HID_Open\n
           to avoid unpredicted behavoir

\param   pstrHidDevice: Structure which contains important data of an HID device

*/
SEBAHID_API INT HID_Init(struct strHidDevice* pstrHidDevice);

natürlich habe ich das struct durch ein int Pointersized ersetzt.
Seltsam ist auch das der Return Wert des Init Knoten exakt dem Wert entspricht der auch vom ole32.dll CoTaskMemAlloc() angelegt wird, ich hätte hier einen Fehlercode, der auch im Header definiert ist erwartet. Scheinbar ist mit dem Init etwas nicht ok.

Code:
/// HID Device return codes
/// HID read buffer contains old data
/// former Read buffer was too small
#define HID_DEVICE_RBUFF_OLD_DATA        1
/// HID action/transfer was successful
#define HID_DEVICE_SUCCESS                0
/// HID device was not found
#define HID_DEVICE_NOT_FOUND            -1
/// HID device is not opened
#define HID_DEVICE_NOT_OPENED            -2
/// HID device is allready opened
#define HID_DEVICE_ALREADY_OPENED        -3
/// Timeout occurs during transfer
#define HID_DEVICE_TRANSFER_TIMEOUT        -4
/// HID transfer failed
#define HID_DEVICE_TRANSFER_FAILED        -5
/// HID transfer report lost
#define HID_DEVICE_REPORT_LOST            -6
/// HID Read buffer overflow
#define HID_DEVICE_RBUFF_OVERFLOW        -7
/// HID Write buffer overflow (could not handle so much data with this protocol)
#define HID_DEVICE_TBUFF_OVERFLOW       -8
/// Invalid handle
#define HID_DEVICE_HANDLE_ERROR            -9
/// Unknown error
#define HID_DEVICE_UNKNOWN_ERROR        -100

Lib ist angehängt.


Angehängte Datei(en)
0.0 .zip  SebaHID2.zip (Größe: 164,35 KB / Downloads: 275)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
29.09.2016, 20:56 (Dieser Beitrag wurde zuletzt bearbeitet: 29.09.2016 21:01 von rolfk.)
Beitrag #15

rolfk Offline
LVF-Guru
*****


Beiträge: 2.302
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
RE: DLL Import externe Struktur in Header bekommen
(28.09.2016 19:51 )hansi9990 schrieb:  Ja, ich habe die beiden Knoten ole32.dll CoTaskMemAlloc() und SebaHID.dll HID_Init() in einem VI zusammengefasst, im Header war der Init so definiert

[code] /**
\fn VOID HID_Init(struct strHidDevice* pstrHidDevice);

Siehst Du das VOID vor der Funktion? Das ist ein Microsoft alias für void und bedeutet, dass diese Funktion GAR NICHTS zurückgibt.

C ist tückisch: void alleine ist nichts, void* ist ein Pointer auf eine Speicherstelle ohne Typedefinition. Das heisst für einen C Compiler ist void* mit allen anderen Pointern kompatibel ohne dass man Typecasts machen muss. Ein nicht void* Pointer ist mit keinem anderen nicht void* Pointer kompatibel, und erfordert einen expliziten Cast um doch zugewiesen werden zu können.

Wenn vor der Funktion LPVOID oder PVOID stehen würde, hiesse das dass die Funktion einen void Pointer zurückgibt. Da die Funktion deklariert ist ohne Rückgabewert, setzt sie das EAX Register nicht explizit. Das heisst wenn Du LabVIEW sagst dass die Funktion etwas zurückgibt, dann liest LabVIEW halt das EAX Register das dann halt mit irgendeinem Wert beschrieben ist, hier scheinbar mit dem Pointer den Du als Parameter übergeben hast da die Funktion diesen scheinbar ins AEX Register kopiert um damit zu arbeiten. Nur kann eine Recompilation der DLL dies durchaus veränderen, entweder durch Änderungen im C Code selber, so dass der Compiler diesen Zeiger in ein anderes Register kopiert da das plötzlich effizienter ist mit Berücksichtigung von Cache, Multithreading und CPU Technologie und ein paar Dutzend andere Low-Level Details von denen Du nie im Leben etwas hören willst. Oder der DLL Bauer verwendet schlicht und einfach einen anderen Compiler oder Compilerversion, die andere Ideen hat wie der Code für optimale Performance erzeugt werden soll. Nur wenn die Funktion auch explizit deklariert und implementiert ist um einen Wert zurückzugeben kannst Du auch erwarten dass dort etwas sinnvolles zurückkommt.

Ich denke dass die Funktion im Prinzip schon etwas richtiges tut, nur scheinbar initialisiert sie nicht den ganzen Speicherbereich sondern nur ein paar Elemente die dem Entwickler wichtig erschienen. Schade dass er dabei vergessen hatte um auch gleich die OVERLAPPED Strukturen mitzuinitialisieren, wenn er denn schon von so einem Feature wie OVERLAPPED Gebrauch machen will.

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30.09.2016, 17:20
Beitrag #16

hansi9990 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 180
Registriert seit: Mar 2015

2019
2014
DE

96xxx
Deutschland
RE: DLL Import externe Struktur in Header bekommen
Hi Rolf

Ich habe dazu auch einen Kollegen befragt der diese dll etwas kennt (bevor ich deinen Beitrag hier gelesen habe) und er hat mir im Prinzip das gleiche gesagt wie du, kein Return.
Wenn ich es weiß dann ist das auch ok denn ich benötige da keinen Rückgabewert.
Das Init soll im Prinzip den pstrHidDevice Bereich initialisieren, macht das aber scheinbar nicht vollständig. Benötigt wird das Init aber auf jeden Fall den ohne geht auch mit der LabView Manager Funktion nichts.
Für mich ist das jetzt nicht wirklich ein Problem und mir ist es auch lieber wenn ich dazu nicht extra die ole32.dll einbinden muss.
Fakt ist, das bisher alles Fehlerfrei läuft und ich keinen Crash mehr hatte (den ich nicht selbst verschuldete Wink)

Vielen lieben Dank nochmal, es hat mich zwar nicht zu einem Experten für den dll Import gemacht, aber dank deiner freundlichen Unterstützung habe ich in diesen Beitrag wieder sehr viel dazugelernt.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  USB Relay DLL import hansi9990 3 8.674 02.09.2019 09:15
Letzter Beitrag: hansi9990
  Aufruf externe DLL Fehler 1097 Lars_Tragl 1 8.482 11.08.2016 16:13
Letzter Beitrag: Freddy
  externe DLL verstehen sarah.bla 7 12.040 05.07.2016 08:19
Letzter Beitrag: sarah.bla
  Fehlende externe Funktion galilio 4 11.410 28.04.2016 12:42
Letzter Beitrag: rolfk
  aus einem Library Import Installer machen galilio 5 11.915 04.04.2016 09:32
Letzter Beitrag: galilio
  Labview Import / DLL debuggen galilio 36 48.237 10.11.2015 21:42
Letzter Beitrag: rolfk

Who read this thread?
1 User(s) read this thread:
Tobi Wan Kenobi

Gehe zu: