AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

PWideChar oder PAnsiChar

Ein Thema von norwegen60 · begonnen am 1. Mär 2018 · letzter Beitrag vom 1. Mär 2018
Antwort Antwort
norwegen60

Registriert seit: 23. Dez 2007
Ort: Schwarzwald
504 Beiträge
 
Delphi 12 Athens
 
#1

PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 02:42
Hallo zusammen,

meine Frage geht in eine ähnliche Richtung wie der Beitrag "String Kovertierung".

Ich bin dabei meine Warnungen bezüglich impliziten Stringkonvertierungen zu überarbeiten. Dabei bin ich auf folgendes Problem gestoßen:
Delphi-Quellcode:
const
  sDLL = 'Splash.dll';
 
var
   haDLL : Cardinal;

procedure TintSplash.Show(sTitel: string);
const
  sBef = 'Show';
var
  fShow: procedure(Titel: WideString); stdcall;

begin
  haDLL := GetModuleHandle(PWideChar(sDLL)); { prüfen ob DLL schon geladen }
  if haDLL = 0 then
    haDLL := LoadLibrary(PWideChar(sDLL)); { DLL dynamisch laden }

  if haDLL <> 0 then
  begin
    @fShow := GetProcAddress(haDLL, PWideChar(sBef));
    fShow(sTitel);
  end
Gehe ich mit dem Mauszeiger auf GetProcAddress bekomme ich als Hilfe Windows.GetProcAddress(Cardinal,PAnsiChar)Method .
Ändere ich die Zeile in  @fShow := GetProcAddress(haDLL, sBef); bekomme ich die Hilfe Windows.GetProcAddress(Cardinal,PWideChar)Method .
Warum wird bei expliziter Wandlung in PWideChar PAnsiChar angezeigt und bei direkter Übergabe des String PWideChar?
Muss ich in den drei Fällen oben überhaupt eine explizite Umwandlung vornehmen? In allen drei Fällen ist der übergebene Parameter eine const die automatisch als String deklariert ist.
Was wäre, wenn ich sDLL als String mit übergeben würde TintSplash.Show(sDLL, sTitel: string); .

Danke für eine Antwort
Gerd
  Mit Zitat antworten Zitat
Ghostwalker

Registriert seit: 16. Jun 2003
Ort: Schönwald
1.299 Beiträge
 
Delphi 10.3 Rio
 
#2

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 06:00
Da in den letzten Versionen von Delphi, der Typ STRING automatisch auf UNICODESTRING gesetzt wurde, werden demzufolge alle Konstanten auch automatisch Unicodestrings. Da Widestrings und Ansistrings andere Typen sind,
wird hier immer konvertiert (und damit auch eine entsprechende Warnung ausgegeben).

Lösung:

Benutz typisierte Konstanten und definier dabei den gewünschten String-Typ

Beispiel:

Delphi-Quellcode:
   const sDll : Widestring = 'Splash.dll';
   const sBuf : widestring = 'Show';
Uwe
e=mc² or energy = milk * coffee²
  Mit Zitat antworten Zitat
CCRDude

Registriert seit: 9. Jun 2011
675 Beiträge
 
FreePascal / Lazarus
 
#3

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 06:22
Beispielhaft an einem Aufruf:
Delphi-Quellcode:
haDLL := LoadLibrary(PChar(sDLL)); // mit sDLL: string
haDLL := LoadLibraryA(PAnsiChar(sDLL)); // mit sDLL: AnsiString
haDLL := LoadLibraryW(PWideChar(sDLL)); // mit sDLL: WideString
Wenn Du eine API-Funktion aufrufst, schau unbedingt, welcher Typ erwartet wird! Von den meisten System-APIs, die Text erwarten, gibt es auch die expliziten *A und *W-Varianten; der Aufruf ohne zeigt bis auf in Uralt-Delphis auf *W, früher auf *A.
  Mit Zitat antworten Zitat
bepe

Registriert seit: 17. Okt 2006
118 Beiträge
 
#4

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 06:25
Hi,

nicht direkt eine Antwort auf deine Frage aber...

Zu vielen/den meisten API Calls gibt es zwei Varianten: Ansi und Widestring. Zum Beispiel GetModuleHandleA und GetModuleHandleW. Du verwendest aber den Alias GetModuleHandle. Dann solltest du auch beim Datentyp einen Alias verwenden.

haDLL := GetModuleHandle(PWideChar(sDLL)); Das funktioniert wenn GetModuleHandle auf GetModuleHandleW verweist (Unicode Delphis). In älteren Versionen geht der verweis auf GetModuleHandleA und dann stimmt der Datentyp nicht mehr.

Delphi-Quellcode:
haDLL := GetModuleHandleW(PWideChar(sDLL)); // wenn du bewusst WideChar möchtest
haDLL := GetModuleHandleA(PAnsiChar(sDLL)); // wenn du bewusst AnsiChar möchtest

// meistens bessser:
haDLL := GetModuleHandle(PChar(sDLL)); // wenn der Typ egal ist

Trotz rotem Kasten, da ein zwei erklärende Worte mehr...

mfg,
bp
  Mit Zitat antworten Zitat
norwegen60

Registriert seit: 23. Dez 2007
Ort: Schwarzwald
504 Beiträge
 
Delphi 12 Athens
 
#5

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 06:59
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
  Mit Zitat antworten Zitat
TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.060 Beiträge
 
Delphi 10.4 Sydney
 
#6

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 08:55
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.
  Mit Zitat antworten Zitat
norwegen60

Registriert seit: 23. Dez 2007
Ort: Schwarzwald
504 Beiträge
 
Delphi 12 Athens
 
#7

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 12:13
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
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#8

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 14:23
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.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.139 Beiträge
 
Delphi 12 Athens
 
#9

AW: PWideChar oder PAnsiChar

  Alt 1. Mär 2018, 14:35
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:24 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz