4. erneute Frage zu Converterror ('const char *' to LPCWSTR)

erneute Frage zu Converterror ('const char *' to LPCWSTR)

  • K

    Ich weiß, dass diese Frage schon x-mal gestellt worden ist, und ich habe mir auch schon viele Antworten dazu durchgelesen, aber so ganz steige ich da noch nicht hinter, und zwar:
    Ich verwende VisualStudio 2005 und natürlich c++. Bei der Windowsprogrammierung kommt in der Funktion

    CreateWindow()

    bei dem zweiten und dritten Parameter

    ...lpClassName, lpWindowName,...

    der Fehler, dass er nicht von 'const char *' nach 'LPCWSTR' convertieren kann.

    Ich habe schon erfahren, dass dagegen

    MultiByteToWideChar()

    oder ein L vor dem String helfen soll. Jedoch funktioniert das nicht. Ich würde jetzt echt gerne wissen, wo der Fehler liegt, dass man nicht einfach so von dem string zu LPCWSTR casten kann. Außerdem würde ich gerne wissen, wie man eine Variable deklarieren kann, die den String für z.B. lpWindowName im richtigen Typ(LPCWSTR) enthält.

    Im übrigen habe ich auch schon versucht, den Character Set bei dem Projekt umzustellen, doch dann kommen Link-errors, mit denen habe ich mich noch nicht so genau beschäftigt, da ich das eben schnell ausprobiert habe und das nicht die ideale Lösung zu sein scheint.

    Mir würden auch Links helfen, wo alle diese Problem leicht verständlich beseitigt werden, wenn es geht auf Deutsch. Zur Not ist Englisch aber auch nicht schlimm.

    0
  • G

    So gut wie jede Windows-Funktion die irgendwo ne Zeichenkette nimmt, gibt es zweimal. CreateWindow() gehört zum Beispiel dazu:
    Einmal CreateWindowA() und CreateWindowW().
    Wenn Unicode aktiviert ist, zeigt CreateWindow() auf CreateWindowW(), wenn es aus ist auf CreateWindowA().
    Seit Visual Studio 2003 oder 2005 oder so, ist dort standardmässig Unicode aktiv.

    Die ...W()-Funktionen nehmen als Strings LPCWSTR* an, während die ...A()-Funktionen LPCSTR* nehmen.

    LPCWSTR sagt msdn: "Pointer to a constant null-terminated string of 16-bit Unicode characters"
    LPCSTR sagt msdn: "Pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters."

    In der msdn findest du dagegen immer z.B.:

    HWND CreateWindow(
     LPCTSTR lpClassName,
     ...

    LPCTSTR sagt msdn ist: "An LPCWSTR if UNICODE is defined, an LPCSTR otherwise."

    Hast du also Unicode an, musst den Funktionen 16Bit-Unicode characters geben, hast du es aus 8Bit-Ansi-Characters.

    CreateWindow(L"ClassName",L"WindowName",...); // Das L bewirkt dabei das du da eine Unicode-Zeichenkette hast.

CreateWindow("Classname","WindowName",...); // Normale 8Bit-Zeichenketten

CreateWindow(TEXT("Classname"),TEXT("WindowName"),...); // Jetzt hast du je nachdem ob Unicode an oder aus ist Unicode-Zeichenketten oder Ansi-Zeichenketten
// ...statt TEXT() geht meistens auch _T() oder nur T()

    msdn sagt zu TEXT() schrieb:

    Identifies a string as Unicode when UNICODE is defined by a preprocessor directive during compilation. Otherwise, the macro identifies a string as an ANSI string.

    TEXT(), L"", etc. funktionieren also nicht mit Variablen - nur mit festem Text.

    Wenn mich nich alles täuscht arbeitet Windows ab Windows 2000 generell mit Unicode-Zeichenketten. Wenn z.B. CreateWindowA() aufgerufen wird muss Windows die übergebenen Zeichenketten erst in Unicode-Zeichenketten selbst umwandeln.
    Einige neuere Funktionen wie z.B. SHGetKnownFolderPath() gibt es gar nicht mehr als Ansi-Version.

    Für den Fall das man andere DLLs oder sonstwas nutzt, die mit Unicode nicht klar kommen, kann man z.B. mittels WideCharToMultiByte() von Unicode-Zeichenketten nach Ansi-Zeichenketten umwandeln, der umgekehrte Weg geht mit MultiByteToWideChar()

    Mehr zu Unicode findet man z.B. in der msdn:
    http://msdn2.microsoft.com/en-us/library/ms776459.aspx

    0
  • K

    Danke für die umfangreiche Antwort, es hat mein Problem leider nicht gelöst. Komischerweise kommt der Konvertierungsfehler nur bei dem Parameter "lpWindowName". Ist Visual Studio vielleicht falsch installiert? Wenn ich jetzt den Character Set auf "Multi-Byte" setze, funktioniert das ganze Programm. In welchen Situationen ist Unicode denn wirklich unumgehbar? In der Praxis scheint ja das andere besser zu funktionieren, oder sehe ich da jetzt etwas falsch?

    0
  • C

    Zeig doch mal etwas umfangreicheren Code - ohne zu wissen, was sich hinter deinen Variablen versteckt, können wir hier nur raten.

    0
Anmelden zum Antworten