LabVIEW DLL in C# verwenden

Hallo zusammen,

ich habe eine kleine DLL in LabVIEW erstellt. Die DLL enthält ein einfaches VI weches eienn Wert verdoppelt. Begonnen habe ich mit einem Double. Die erstellte DLL habe ich dann in C# aufgerufen.

Aufrufsyntax:
[DllImport("D:\malZwei.dll")]
static extern double MalZwei(double zahl);

Das funktionierte auch wunderbar. Alles bestens. Nun versuche ich allerdings, einen String zu übergeben. Daran scheiter ich. Kann mir jemand verraten, welche Typen ich in der LabVIEW-DLL verwenden muss und welche Typen dazu passend in C# abgerufen werden können? Mir schwebt folgender Aufruf vor:

[DllImport("D:\malZwei.dll")]
static extern void MalZwei(string str);

Es soll also lediglich ein String von C# nach LabVIEW übergeben werden.

Vielen Dank,
Torsten

Anzeige

' schrieb:Es soll also lediglich ein String von C# nach LabVIEW übergeben werden.

Also in Sachen C# (also .Net) kenn ich mich gar nicht aus.

Ich weiß nur eins: Strings, also AnsiString, WideString etc, per DLL zu übergeben ist immer mit Problemen verbunden. Das liegt am Memorymanager eines jeden Systems, der die Strings (beachte: die haben einen Datenoverhead) verwaltet. Willst du zwei Systeme verbinden (DLL!), müssen sich die Memorymanager vertragen, wenn z.B. Strings übergeben werden sollen. Strings als solche würde ich nie übergeben - lieber PChars.

Definiere die Daten als PChar. Alloziere in C# (wenn das überhaupt noch geht) einen Speicher, auf den der PChar zeigt. Den Pointer übergibst du dann. Die Gegenseite soll die Daten dann zu sich kopieren. Dann kann nichts passieren.

(Und falls PChar in C# [*grübel*][CundKeinPChar?][*KannNichtSein*] nicht geht: gibst einen "const string"?)

' schrieb:Also in Sachen C# (also .Net) kenn ich mich gar nicht aus.

Ich weiß nur eins: Strings, also AnsiString, WideString etc, per DLL zu übergeben ist immer mit Problemen verbunden. Das liegt am Memorymanager eines jeden Systems, der die Strings (beachte: die haben einen Datenoverhead) verwaltet. Willst du zwei Systeme verbinden (DLL!), müssen sich die Memorymanager vertragen, wenn z.B. Strings übergeben werden sollen. Strings als solche würde ich nie übergeben - lieber PChars.

Definiere die Daten als PChar. Alloziere in C# (wenn das überhaupt noch geht) einen Speicher, auf den der PChar zeigt. Den Pointer übergibst du dann. Die Gegenseite soll die Daten dann zu sich kopieren. Dann kann nichts passieren.

(Und falls PChar in C# [*grübel*][CundKeinPChar?][*KannNichtSein*] nicht geht: gibst einen "const string"?)

Danke für die guten Infos. C# und C sind nicht so verwandt wie es sich anhört, manchmal leider und manchmal zum glück nicht.

So gibt es in C# zwar Zeiger, aber der dazugehörige code muss als UNSAFE deklariert werden. ich persönlcih vermeide sowas gerne. Aber du hast mich auf die Idee gebracht, einen String nciht direkt als String zu übergeben. Ich versuche es mal als Byte-Array. Mit Zahlenwerten hatte ich bisher ja keine Probleme, mal schauen wies mit Array aussieht. Und sonst werd ich mich mal nach static Strings umschauen.


LG
Torsten

' schrieb:Ich versuche es mal als Byte-Array. Mit Zahlenwerten hatte ich bisher ja keine Probleme

Ein Array ist aber keine Zahl - eher ein String.

In Nicht-.Net gibt es statische Arrays und dynamische. Statische Arrays haben normalerweise keinen Overhead, dynamische schon (zumindest in Delphi for Win32).

[*grübel*]

Du bekommst mit einem Array ein ähnliches Problem wie mir Strings. Arrays sind komplexte Datentypen, die auch nur mit Pointern übergeben werden können. Ich gehe aber mal davon aus, dass die C#-IDE (respektive der Kompiler) so gebaut ist, dass ein solcher Pointer nach außenhin gar nicht sichtbar und zugänglich ist. Nicht-komplexte Datentypen wie double werden über den Stack übergeben, komplexe Datentypen eben indirekt per Pointer.

Über die richtigen Google-Schlagwörter gefunden:

http://zone.ni.com/devzone/cda/epd/p/id/6050

Da hab ich nun mal abgekupfert. An meinem VI kommt der richtige String an (habe ihn über einen Dialog ausgegeben). Allerdings sollte das VI eigentlich eine TXT Datei erzeugen. Das passiert leider nicht. Also habe ich mir mal ausgeben lassen ob Fehler auftreten. Siehe da:

Fehlercode: 1043
Beschreibung: Methodenknoten in Gen.vi->Gen.vi.ProxyCaller

An der Stelle kann ich also erstmal weiter Suchen. Dieser Fehler tritt nur ein, wenn ich das VI über die DLL aufrufe, nicht wenn ich es manuell starte.

Weitere erkenntnisse:

Zitat:Problem:
I've completed my program in LabVIEW and it runs without errors. However when I turn the program into an executable I get error 1043 "The property or method is not supported in this version of LabVIEW." I'm using the same version of the Run Time engine as the LabVIEW development environment in which I created my program. Why am I getting this version error?

Solution:
"Version" in this case refers to the Run Time engine versus the LabVIEW development environment. There are various property nodes and invoke nodes that are only available in the development environment. To find out if a property or method is supported in the Run Time engine open the detailed help for the property or method of interest. You'll see a chart at the bottom of the help document that lists various remarks about the node that resembles the following.

[Quelle: http://digital.ni.com/public.nsf/allkb/1E1...625731C006CCB5A]

Anscheinend kann ich das VI also so nicht lassen und muss mir was neues ausdenken. Schade.