LabVIEW
tchar nicht definiert bei DLL Einbindung
@Fabi_testo wrote:
Hallo,
ich habe ein Projekt bekommen, bei dem ich Messgeräte mit dll Library über LabView auslesen soll. Bei dem DLL Import kam allerdings ein Fehler den ich nicht ganz verstehe. Ich muss dazu sagen, dass ich ein Anfänger bin, was LabView betrifft.
Beim Import kam folgende Meldung:
"
TESTOEMUSB_API int WINAPI TESTOEMUSB_GetSerialNumber( unsigned int uDeviceNumber, TCHAR* szSerialNumber, unsigned int dwMaxLength );
Folgende Symbole sind nicht definiert:
TCHAR;Nicht definierte Symbole können den Assistenten daran hindern, Funktionen und Parameter zu erkennen. Prüfen Sie zur Problemlösung die Header-Datei und fügen Sie ggf. Präprozessor-Definitionen hinzu. Klicken Sie auf die Zurück-Schaltfläche, um zur vorigen Seite des Assistenten zu wechseln und eine Präprozessor-Definition hinzuzufügen (z. B. "NIAPI_stdcall = __stdcall" oder "NIAPIDefined = 1").
"
Im Anhang findet ihr ein Bild, bei welchem Schritt der Fehler entsteht. Ich wollte "TESTOEMUSB_GetSerialNumber()" anklicken und da zeigt es mir diesen Fehler an.
Kann mir jemand weiterhelfen? Was muss ich machen damit es funktioniert?
Vielen Dank schon einmal im Vorraus.
Viele Grüße
Fabi
Die Funktionsdefinition ist so wie im Header vorhanden völlig falsch.
TCHAR ist ein WinAPI Datentyp, und deshalb müuste man die windows.h headers eines Windwos SDKs mit einbeziehen was aber ein rieseger Parseaufwand für den Import Library Wizard ist, und zudem enthalten die Windows Headers C Konstrukte die die LabVIEW Call Library Node nie unterstützen kann, und die für den Import Library Wizard auch einen unüberwindlichen Stolperstein bilden.
TCHAR als Datentyp ist eine Microsoft Erfinding die abhängig davon ob man einen Code als Unicode oder nicht compiliert im C Preprozessor in WCHAR oder CHAR umgesetzt wird. Da das aber eine komplete Inkompatibilität der zwei möglichen Libraries bewirkt wird mit der gleichen Preprozessormagie auch jeweils eine Funktion mit einem angefügten U oder A beim Funktionsnamen erzeugt. Dies Preprozessormagie ist aber in Deinem Header nirgends zu sehen, weshalb dieser Prototyp schlichtweg unsinnig ist. Du als Benützer der entsprechenden Library kannst nirgendwo sehen ob die Library mit dem UNICODE Preprozessor Keyword compiliert wurde, und weisst deshalb auch nicht ob diese Definition für die Clientapplikation ebenfalls nötig ist oder nicht. Wenn Du es verkehrt erwischt dann bekommst Du im besten Fall einen Crash, im schlechteren Fall komische Strings.
Erschwerend kommt hierbei hinzu dass die Call Library Node ohne extra Mühe im Diagramm selber nur ANSI Strings unterstützt, also eine eventuel als UNICODE compilierte Library nicht einfach so verwenden kann.
Jedenfalls ist zu sagen, dass die Headerdefinition dieser Funktion grundsätzlich falsch ist. Entweder ist die Library mit dem UNICODE Define compliiert und dann sollte TCHAR effektiv explizit WCHAR sein (und ist die Library nicht ohne weiteres mit der CLN in LabVIEW aufzurufen oder es ist ohne dieses Define compiliert und dann sollte TCHAR effektiv char sein. Wenn Du sicher weisst dass die Library nicht als Unicode compiliert wurde, was nur aus der Dokumentation eventuel ersichtlich werden könnte, kannst Du im Importlibrary Wizard einen Define hinzufügen in der Form "TCHAR=char".
@Fabi_testo wrote:
Hallo Rolf Kalbermatter,
ich habe gerade mit einem Entwickler geredet der mir sagte, dass die Library mit dem UNICODE Define compliiert wurde.
Kann ich das Ganze dann überhaupt noch irgendwie zum Laufen bekommen?
Grüße Fabian und vielen Dank für Ihre Mühe
Was ist Deine Erfahrung mit C Programmierung? Grundsätzlich ist es machbar und sogar ohne extrem viel Arbeit von Deiner Seite, aber ohne etwas C Kenntnisse wird das ein Alptraum für Dich.
Da LabVIEW grundsätzlich mit MBS (MultiByteSequence) Strings arbeitet musst Du die LabVIEW Strings von und nach 16 Bit Unicode übersetzen. Dazu gibt es sogar eine VI Library von mir die Du in diesem Post finden kannst. Ein Problem besteht mit dieser Library! Sie wurde schon vor langer Zeit gemacht als 64 Bit Betriebssysteme nicht bestanden und deshalb geht sie noch davon aus dass man Pointer als 32 Bit Integers behandelen kann. Solange Du nicht auf 64 Bit Windows gehst ist das kein Problem, aber zur Sicherheit sollte man bei allen Call Library Nodes mit einem 32 Bit Integer Parameter die eigentlich einen Pointer darstellen, auf den neuen PointerSized Datatype umstellen und eventuelle FrontPanel Elemente ebenfalls anpassen.
Eine andere interessante Seite zu Unicode in LabVIEW (aber nicht leicht bekömmlich, falls Du alles begreifen willst) kannst Du hier finden.
Ich habe mal ein Beispiel gemacht für die Funktion im ersten Post. Da gibt es aber eingie Dinge die ich nicht weiss und deshalb nicht fixfertig machen konnte.
- Der DLL Name muss in die Call Library node eingefügt werden.
- Der Funktionsaufruf könnte eventuel auch reentrant konfiguriert werden, aber das kann nur der DLL Programmierer selber sagen ob das ohne Probleme geht. Grundsätzlich ist es die sicherere Art um es nicht-reentrant aufzurufen.
- Ich kann nicht beurteilen wievele Character der zurückgegebene String maximal haben könnte. Ich nahm mal 256 an aber das könnte viel zu viel sein (nicht weiter schlimm ausser dass kurzfristig ein paar Bytes mehr in der Applikation verwendet werden dann nötig) oder zuwenig (dann bekämest Du nur einen Teil der Serlialnumber zurück).
- Ich weiss nicht was die Bedeuting des Ruckgabewertes der Funktion ist. Ich habe mal angenommen dass 0 als Erfolg gesehen werden sollte und alles andere einen Errorcode sein würde, aber das kann völlig verkehrt sein und muss von Dir eventuel angepasst werden.
- Das Icon darfst Du Dir selber aussuchen 
Hallo,
Vielen Dank für das Programm. Ich habe es vorher versucht, da hat es auch funktioniert, aber jetzt geht es plötzlich nicht mehr. Es zeigt mir immer folgenden Fehler an:
Was mache ich denn nun schon wieder falsch?
Grüße
Fabian
