Pb Edition de Texte !!!

Signaler
Messages postés
39
Date d'inscription
samedi 20 mars 2004
Statut
Membre
Dernière intervention
5 novembre 2008
-
Messages postés
1910
Date d'inscription
vendredi 18 juin 2004
Statut
Modérateur
Dernière intervention
14 novembre 2014
-
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 ?

9 réponses

Messages postés
1466
Date d'inscription
mardi 20 février 2007
Statut
Membre
Dernière intervention
7 février 2011
1
Jette un oeil ici.
J'ai appris avec ça et je n'ai jamais eu de problème.

Cordialement, uaip.
Messages postés
1910
Date d'inscription
vendredi 18 juin 2004
Statut
Modérateur
Dernière intervention
14 novembre 2014
13
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.
Messages postés
452
Date d'inscription
jeudi 4 décembre 2003
Statut
Membre
Dernière intervention
19 décembre 2008
10
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 CSavon
Messages postés
1910
Date d'inscription
vendredi 18 juin 2004
Statut
Modérateur
Dernière intervention
14 novembre 2014
13
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.
Messages postés
39
Date d'inscription
samedi 20 mars 2004
Statut
Membre
Dernière intervention
5 novembre 2008

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 ?
Messages postés
39
Date d'inscription
samedi 20 mars 2004
Statut
Membre
Dernière intervention
5 novembre 2008

ou bien faudrait il mettre de la compilation conditionnelle partout pour avoir qq chose de générique ?
Messages postés
1910
Date d'inscription
vendredi 18 juin 2004
Statut
Modérateur
Dernière intervention
14 novembre 2014
13
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.
Messages postés
452
Date d'inscription
jeudi 4 décembre 2003
Statut
Membre
Dernière intervention
19 décembre 2008
10
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 CSavon
Messages postés
1910
Date d'inscription
vendredi 18 juin 2004
Statut
Modérateur
Dernière intervention
14 novembre 2014
13
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.