Bonjour, j'ai un petit soucis en voulant sauvegarder le contenu d'une EditBox dans un fichier; j'ai que la moitier du contenu qui est sauvegardé !

OPENFILENAME ofn;
TCHAR szFile[_MAX_PATH]={0};

ZeroMemory(&ofn, sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hwndOwner = hWnd;
ofn.lpstrFile = szFile;
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFilter = L"Fichiers Texte(*.TXT)\0*.txt\0Tous les fichiers(*.*)\0*.*\0";
ofn.nFilterIndex = 0;
ofn.Flags = OFN_PATHMUSTEXIST | OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT;

if (GetSaveFileName(&ofn)==TRUE)
{
   HANDLE hFile, hBuffer;
   DWORD FileSize, nbcharRead=0 ;
   
   FileSize = GetWindowTextLength(hWndEdit);
   hBuffer = (HANDLE)SendMessage(hWndEdit, EM_GETHANDLE, 0, 0L);
   hBuffer = LocalLock(hBuffer);
   hFile = CreateFile(szFile, GENERIC_READ|GENERIC_WRITE, 0,NULL,
   CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
   WriteFile(hFile, hBuffer, FileSize, &nbcharRead, NULL) ;

  wsprintf((LPWSTR)szBuffer,L"%d",nbcharRead);
   MessageBox(NULL, (LPCWSTR) szBuffer, (LPCWSTR)L"nbcharRead", MB_OK);   => pourtant ça donne la longueur correct

   CloseHandle(hFile);
   LocalUnlock(hBuffer);
}


Avez vous une idée ?

Jette un oeil ici.
J'ai appris avec ça et je n'ai jamais eu de problème.

Cordialement, uaip.

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.

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.

--

Vive le C

Savon

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.

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 ?

ou bien faudrait il mettre de la compilation conditionnelle partout pour avoir qq chose de générique ?

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.

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?

--

Vive le C

Savon

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.