' 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

' 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

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

' 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

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