Impossible de convertir le paramètre 1 de 'const char *' en 'LPCWSTR'.

Question

J'ai un code simple qui fait des choses pour les fichiers et j'essaie de le porter sur Windows. J'ai quelque chose qui ressemble à ceci :

int SomeFileCall(const char * filename){
#ifndef __unix__
    SomeWindowsFileCall(filename);
#endif
#ifdef __unix__
    /**** Some unix only stat code here! ****/
#endif
}

la ligne SomeWindowsFileCall(filename); provoque l'erreur du compilateur : cannot convert parameter 1 from 'const char *' to 'LPCWSTR'

Comment puis-je résoudre ce problème, sans modifier le SomeFileCall prototype ?

Answer 1

La plupart des API Windows qui prennent en charge des chaînes de caractères ont deux versions : l'une prend en charge char * et qui prend WCHAR * (ce dernier est équivalent à wchar_t * ).

SetWindowText par exemple, est en fait une macro qui se développe en SetWindowTextA (qui prend char * ) ou SetWindowTextW (qui prend WCHAR * ).

Dans votre projet, il semble que toutes ces macros fassent référence aux versions -W. Ceci est contrôlé par l'option UNICODE (qui est définie si vous choisissez l'option de projet "Use Unicode Character Set" dans Visual Studio). (Certaines fonctions de la bibliothèque d'exécution C et C++ de Microsoft ont également des versions ANSI et large. La version que vous obtenez est sélectionnée par la macro de préprocesseur portant le même nom _UNICODE qui est également définie par ce paramètre du projet Visual Studio).

En règle générale, les fonctions -A et -W existent dans les bibliothèques et sont disponibles, même si votre application est compilée pour Unicode. (Il existe des exceptions ; certaines fonctions plus récentes ne sont disponibles que dans les versions "larges").

Si vous avez un char * qui contient du texte dans la bonne page de code ANSI, vous pouvez appeler la version -A explicitement (par exemple, SetWindowTextA ). Les versions -A sont typiquement des enveloppes qui font des copies en caractères larges des paramètres de la chaîne et passent le contrôle aux versions -W.

Une autre solution consiste à créer vos propres copies de caractères larges des chaînes de caractères. Vous pouvez le faire avec MultiByteToWideChar . L'appeler peut s'avérer délicat, car il faut gérer les tampons. Si vous pouvez vous en sortir en appelant directement la version -A, c'est généralement plus simple et déjà testé. Mais si votre char * utilise UTF-8 ou tout autre encodage que la page de code ANSI actuelle de l'utilisateur, vous devez effectuer la conversion vous-même.

Informations sur les bonus

Le suffixe -A signifie "ANSI", qui était le terme courant sous Windows pour désigner un jeu de caractères à un octet.

Le suffixe -W signifie "Wide" (c'est-à-dire que les unités d'encodage sont plus larges qu'un seul octet). Windows utilise spécifiquement l'UTF-16 little-endian pour les chaînes de caractères larges. La documentation MSDN appelle cela simplement "Unicode", ce qui n'est pas tout à fait exact.

Answer 2

Configurez votre projet pour utiliser le jeu de caractères ANSI. (Général -> Jeu de caractères)

Que sont les TCHAR, WCHAR, LPSTR, LPWSTR, LPCTSTR, etc.

typedef const wchar_t* LPCWSTR ;

Answer 3

{propriétés du projet->avancé->jeu de caractères->utiliser le jeu de caractères multi-octets} Si vous faites ces étapes, votre problème est résolu.

Answer 4

Vous construisez avec WinApi en mode Unicode, donc tous les paramètres de chaîne se résolvent en chaînes larges. La solution la plus simple serait de changer la WinApi en ANSI, sinon vous devez créer un fichier wchar_t* avec le contenu de filename et l'utiliser comme argument.

Answer 5

J'ai pu résoudre cette erreur en réglant le jeu de caractères sur "Utiliser le jeu de caractères multioctets" [Propriétés du projet-> Propriétés de configuration -> Général -> Jeu de caractères -> "Utiliser le jeu de caractères multioctets".