OEM TO ANSI

' schrieb:Die beiden Parameter sind von Typ String und C String Pointer.

siehe MSDN http://msdn2.microsoft.com/en-usbrary/ms647473.aspx

Parameters

lpszSrc
[in] Pointer to the null-terminated string to translate.
lpszDst
[out] Pointer to the buffer for the translated string. If the CharToOem function is being used as an ANSI function, the string can be translated in place by setting the lpszDst parameter to the same address as the lpszSrc parameter. This cannot be done if CharToOem is being used as a wide-character function.

Gruss
Roland

Ich hab die Parameter auch von dem Typ aber es funktioniert leider immer noch nicht.
Ich weiß leider nicht was ich noch falsch mache oder beachten muss. :-(

' schrieb:Versuchs mal so.
long CharToOemA(CStr lpszSrc , CStr lpszDst );

Gruss
Roland

Für mich eine gute Gelegenheit, mein VI durch RolfK zu prüfen

Hmm das Diagram scheint im Prinzip korrekt. Muss natürlich noch die CLN Konfiguration stimmen aber davon gehe ich bei Dir mal sicher aus

Rolf Kalbermatter

' schrieb:Hab es so gemacht aber LabVIEW stürtzt immer noch ab. Hier mal mein VI

1. Windows APIs benützen praktisch immer stdcall calling convention.

2. Es wäre eine gute Idee um nach dem String Size noch ein Increment einzubauen. LabVIEW hängt an den Source String nämlich noch einen NULL Character, da dieser als C String übergeben wird. Da der Destinationstring aber aus lauter NULL Charactern besteht, bin ich mir nicht sicher ob LabVIEW hier nicht eine Optimalisierung macht und dieses Anhängen eines NULL Characters weglässt. Damit wäre der Destinationsstring aber ein Byte kürzer und hätte für den NULL Character den AnsiToOemA anfügen will, keinen Platz mehr.

Oder Du verwendest AnsiToOemBuffA. Das hat einen dritten extra length Parameter der der Funktion die Länge des Buffers für den Destinationstring mitteilt. Das ist die sicherste Variante denn je nach Codepage kann es sein dass Du plötzlich mit Multibyte Charactern zu tun bekommst die nicht mehr die gleiche Bytelänge zwischen der Ansi und Oem Codepage haben (und der Destinationsstring kann damit theoretisch langer werden dann der Sourcestring war).

Rolf Kalbermatter

' schrieb:1. Windows APIs benützen praktisch immer stdcall calling convention.

2. Es wäre eine gute Idee um nach dem String Size noch ein Increment einzubauen. LabVIEW hängt an den Source String nämlich noch einen NULL Character, da dieser als C String übergeben wird. Da der Destinationstring aber aus lauter NULL Charactern besteht, bin ich mir nicht sicher ob LabVIEW hier nicht eine Optimalisierung macht und dieses Anhängen eines NULL Characters weglässt. Damit wäre der Destinationsstring aber ein Byte kürzer und hätte für den NULL Character den AnsiToOemA anfügen will, keinen Platz mehr.

Oder Du verwendest AnsiToOemBuffA. Das hat einen dritten extra length Parameter der der Funktion die Länge des Buffers für den Destinationstring mitteilt. Das ist die sicherste Variante denn je nach Codepage kann es sein dass Du plötzlich mit Multibyte Charactern zu tun bekommst die nicht mehr die gleiche Bytelänge zwischen der Ansi und Oem Codepage haben (und der Destinationsstring kann damit theoretisch langer werden dann der Sourcestring war).

Rolf Kalbermatter

Vielen Dank für die Unterstützung, an stdcall hat es gelegen. Jetzt funktioniert es.

' schrieb:Vielen Dank für die Unterstützung, an stdcall hat es gelegen. Jetzt funktioniert es.

Trotzdem Punkt zwei nicht vergessen. Auch wenn es zu laufen scheint heisst das noch lange nicht dass die Funktion nicht ein Byte mehr in den Buffer schreibt als dass LabVIEW an die Funktion mitgibt. Und solche off by 1 Byte Fehler können lange ohne sichtbare Auswirkung sein, aber leise im Hintergrund allerlei Dinge korrumpieren, bis dann entweder LabVIEW irgendwann abstürzt, oder noch gemeiner, Du bei einem Abspeichern eines angepassten VIs, korrumpierte Datenstrukturen auf die Disk schreibst und Dein VI beim nächsten Mal nicht mehr geladen werden kann.

Rolf Kalbermatter