wsprintf((LPWSTR)szBuffer,L"%d",nbcharRead);
MessageBox(NULL, (LPCWSTR) szBuffer, (LPCWSTR)L"nbcharRead", MB_OK); => pourtant ça donne la longueur correct
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 4 nov. 2008 à 22:31
Salut,
Il parait que tu en Unicode. Dans ce cas GetWindowTextLength() te retournera le nombre de caractères de l'Edit. Or, le buffer retourné par le message EM_GETHANDLE est deux fois plus grand car chaque caractère en Unicode occupe deux octets. WriteFile() sauvera donc seule la première moitié du buffer. Pour que to Edit ne soit pas Unicode, crée le avec CreateWindowExA(). Bien noter le A à la fin du nom de la fonction.
julienbj
Messages postés452Date d'inscriptionjeudi 4 décembre 2003StatutMembreDernière intervention19 décembre 200815 5 nov. 2008 à 02:08
Tu peux aussi sauvegarder ton message en unicode dans le fichier.
Auquel cas, tu n'as qu'à faire FileSize * sizeof(TCHAR) dans ton WriteFile. Ainsi, sera bon si tu compiles en Unicode ou en ASCII.
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 5 nov. 2008 à 03:36
julienbj >> Oui mais de cette façon son fichier ne sera pas vraiment Unicode car le premier caractère ne doit pas être à la 1ère position mais plutôt à la 3ème. Les deux premiers octets d'un fichier texte Unicode sont 0xFF et 0xFE qu'il faudra mettre avant d'ajouter le texte.
Vous n’avez pas trouvé la réponse que vous recherchez ?
ElectricalMan
Messages postés39Date d'inscriptionsamedi 20 mars 2004StatutMembreDernière intervention 5 novembre 2008 5 nov. 2008 à 10:04
super les mecs, merci ça marche nickel :)
racpp >> je m'en doutais bien que ça clochait qq part à cause de l'UNICODE
julienbj >> ça marche bien aussi ta solution, même si, comme disait "racpp", pour respecter la norme Unicode il faut rajouter le marqueur de l'ordre du flux. C'est le BOM (Byte Order Mark) qui vaut 0xFEFF et sera représenté 0xFF 0xFE sur une machine little endian Windows et 0xFE 0xFF sur les machines big endian. Ce marqueur est indispensable pour qu'un fichier texte soit vu comme fichier Unicode, même si ça marche sans chez moi ! ça doit permettre donc de décoder correctement les caractères Unicode. Donc au niveau de mon code :
...
#ifdef UNICODE
WCHAR BOM = 0xFEFF ;
WriteFile(hFile, &BOM, sizeof(BOM), &nbcharRead, NULL) ;
WriteFile(hFile, hBuffer, FileSize * sizeof(TCHAR), &nbcharRead, NULL) ;
#endif
...
Une question : qu'est ce qui est plus interresant AINSI ou UNICODE ?
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 5 nov. 2008 à 18:37
Puisque c'est pendant l'exécution que ça se passe, et non pas à la compilation, je pense qu'il est préférable d'utiliser IsWindowUnicode() pour déterminer si le controle est Unicode ou non.
L'intérêt de l'Unicode réside dans le support multilingue. En effet, il permet aux applications de pouvoir utiliser toutes les langues de la planète. Son inconvénient est d'occuper deux fois plus d'espace, disque ou mémoire, que l'ANSI. N'utiliser Unicode donc que quand c'est indispensable.
julienbj
Messages postés452Date d'inscriptionjeudi 4 décembre 2003StatutMembreDernière intervention19 décembre 200815 5 nov. 2008 à 20:11
Pour l'écriture en Unicode, je suis d'accord sur le principe, il faut mettre un BOM si le fichier doit être partagé par différentes applis, entre différents utilisateurs, ...
Si il s'agit d'un fichier de config propre à une appli, pourquoi mettre le BOM? Plus compliquer à écrire et à relire...
racpp >> Qu'est-ce qui permettra de choisir entre réaliser une appli en UNICODE ou en ANSI? Les performances sont-elles les mêmes?
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 5 nov. 2008 à 23:25
julienbj >> Personnelement je n'utilise Unicode que pour les applications multilingues. Surtout quand il s'agit de langues totalement différentes. Pour les performances, Unicode serait préférable dans certains cas. Les systèmes NT étant essentiellement Unicode il est plus direct d'appeler les versions Unicode des fonctions au lieu des versions ANSI puisque ces dernières ne font que traduire en Unicode les chaines passées en paramètres avant de les rediriger vers les premières. Cette traduction et cette redirection coûtent beaucoup de cycles au processeur surtout quand c'est répétitif.