PWideChar oder PAnsiChar

[TiGü]

Zitat von norwegen60:

Hallo zusammen,

Danke für die Antwort. Dann stimmt ja meine obiger Code. An die typisierten Konstanten hatte ich auch schon gedacht.
Drei Fragen sind aber noch offen:

1. Gibt es irgendetwas was man beachten muss, wenn man PWidechar(sDLL) anwendet?
2. Warum wird unter dem dem Mauszeiger bei @fShow := GetProcAddress(haDLL, PWideChar(sBef)); in der Hilfe Windows.GetProcAddress(Cardinal,PAnsiChar)Method angezeigt obwohl es für GetProcAddress die A- und die W-Variante gibt?
3. Bei der Zuweisung sString := wWideString; oderwWideString := sString; gibt es keine Kompiler-Warnung. Hier gehe ich also davon aus, dass diese absolut konfliktfrei verläuft. Korrekt?

Grüße
Gerd

1. Nein.
2. Immer mit Strg+Linksklick zur eigentlichen Definition gucken und den Hint ignorieren.
3. Ja.

[norwegen60]

Zitat von TiGü:

1. Nein.
2. Immer mit Strg+Linksklick zur eigentlichen Definition gucken und den Hint ignorieren.
3. Ja.

Das nenne ich mal eine eindeutige Antwort.
Linksklick brachte aber für mich auch nicht die Sicherheit, da der trotz PWideChar auf den ersten dieser beiden Implementationen gesprungen ist.

Delphi-Quellcode:

function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; external kernel32 name 'GetProcAddress';
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC;

Aber jetzt bin ich sicher, dass meine Umstellung korrekt ist

Danke

[Luckie]

Spätestens seit XP endet jeder API Aufruf bei der W-Version. Selbst wenn man explizit die A-Version aufruft, Windows leitet das intern an die W-Version weiter.

[himitsu]

Win32API-Typname = Pascal/Delphi-Typename

LPCSTR = PAnsiChar
LPCWSTR = PWideChar

Zitat:

Leitet weiter

Joar, aber inkl. Typkonvertierung, also muß man bei der ANSI-API dennoch ANSI übergeben, auch wenn es letztendlich beim Unicode landet.