![]() |
Daten einer Struktur aus LV einer DLL übergeben - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +---- Forum: DLL & externer Code (/Forum-DLL-externer-Code) +---- Thema: Daten einer Struktur aus LV einer DLL übergeben (/Thread-Daten-einer-Struktur-aus-LV-einer-DLL-uebergeben) Seiten: 1 2 |
Daten einer Struktur aus LV einer DLL übergeben - IchSelbst - 07.05.2007 09:17 ' schrieb:habe jetzt mal verschiedene sachen ausprobiert:Hast du sehr gut gemacht. :top: Zitat:was mich jetzt stutzig macht, warum bei 16byte keine fehlermeldung kommt.Mich nicht. ![]() Zitat:müsste hier nicht auch eine fehlermeldung kommen?Möglicherweise nicht. Ich gehe schon davon aus, dass im Großen und Ganzen schon die 4er-Schritte im Speicher eingehalten werden. Halt nur von einem Parameter zum anderen. Gerade am Stack nicht die 4er-Schritte einzuhalten wäre eine "Quälerei" für den Prozessor. Jeder Parameter für sich beginnt immer an einer durch vier teilbaren Stelle. Ob da irgendwann mal 3 leere Bytes vorhanden sind, das interessiert keinen. Die beste Überprüfung ob alles funktioniert ist, den Rückgabewert, der ja mittels des dritten Parameters (eines Pointer) zurückgegeben wird, zu verifizieren. Wenn der Rückgabewert stimmt, stimmt auch die Übergabe des Pointers. Wenn die Übergabe des Pointers stimmt, stimmt der Rest auch. Würde der Rückgabewert nicht plausibel sein, würde die Übergabe des Pointers nicht stimmen. Dann wird's kritisch. Daten einer Struktur aus LV einer DLL übergeben - rolfk - 12.06.2007 14:00 ' schrieb:Jawohl, alles klar. So würde es jeder haben wollen (die Datenübergabe mein ich). Gehen tuts schon mit "Adapt to Type" oder wie das auf Deutsch heissen mag. Nur ist die Struktur die LabVIEW dann an die DLL gibt selten das, was die DLL erwartet (ausser die DLL wurde spezifisch dafür geschrieben um mit LabVIEW Datentypen zu arbeiten). Zitat:Lösung: Die Wahl eines PChar Pointers ist wohl nur sehr selten sinnvoll (ausser es handelt sich hier um eine unglückliche Übersetzung in LabVIEW). Wenn PChar für einen Pascalstring steht, was ich hier mal annehme, fügt LabVIEW am Anfang des Pointers ein Byte ein, das die Länge der übergebenen Daten in Bytes angibt. Limitiert den Buffer auch gleich auf maximal 256 Bytes. Gebrauch eines C String Pointers erscheint mir dann auch sinnvoller. Aber: Der Unterschied zwischen einem C String Pointer oder einem Bytearray ist nur irrelevant wenn es darum geht Daten an die DLL zu übergeben. Für C String Pointers die zurückgegeben werden an das LabVIEW Diagram, scannt LabVIEW am Ende des Aufrufs den Buffer nach einem NULL Character und reduziert die Bufferlänge auf diese Länge. Zitat:Der Typ Bool ist je nach Programmiersprache int8 oder int32. In LV int32. Das mit den Bitpositionen geht zwar auch, dann ist es aber kein expliziter Bool. Der Typ Bool wird wie eine normale Int-Zahl gespeichert. Lediglich der Wertebereich ist anders. Bool kennt nur zwei Werte: "Null" und "ungleich Null" (wobei "ungleich Null" praktischerweise, aber auch nur in den Fällen einer Zuweisung, mit Eins gleichzusetzen ist) Für Windows 32bit ist BOOL ein 32bit integer wo 0 == FALSE und !0 == TRUE gilt, während BOOLEAN ein 8 Bit Iinteger ist mit gleicher Bedeutung. C++ definiert auch noch bool als 8bit integer. Alle anderen Boolean Deklarationen sind kundenspezifisch und nur durch Lesen der entsprechenden Headerdateien oder Dokumentation eindeutig zu identifizieren. Rolf Kalbermatter |