CFile && CString en UNICODE

Salut a tous,

J'ai un projet qui doit etre en unicode, embedded visual oblige.

Losque j'ecris dans un CFile, je me retrouve avec des espaces entre chaque caracteres... j'ai bien vu un thread qui parle du meme probleme, mais sa solution maison est rafistolée :p

http://www.developpez.net/forums/vie...ighlight=cfile

Voici mon code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

void SaveCfg(CString FileName, CCPViewerView* pView) { // Opening file CFile* MyFile = new CFile(); MyFile->Open(FileName.GetBuffer(0),CFile::modeWrite|CFile::modeCreate); CString buffer; char endl; endl = '\n';   // Writing connection informations buffer.Format(_T("Config file")); MyFile->Write((void*)(buffer.GetBuffer(buffer.GetLength())),buffer.GetLength()); MyFile->Write((void*)(&endl),1);   buffer.Format(_T("%s"),pView->m_Lang); MyFile->Write((void*)(buffer.GetBuffer(buffer.GetLength())),buffer.GetLength()); MyFile->Write((void*)(&endl),1);   MyFile->Close(); delete MyFile; }

---

Accessoirement, ce qui m'intrigue c'est que l'unicode pose "probleme" a l'ecriture et pas a la lecture qui se passe bien chez moi.

D'avance merci!!

Il y a peut être une piste avec une fonction du style W2A() qui permet de faire une conversion sur la taille des données. Perso, j'ai pas réussi à l'utiliser (d'où la solution rafistolée... :D ), mais si tu y arrives ou si quelqu'un peut donner quelques conseils sur son utilisation...

Code:

---

1 2	char endl;

---

On n'utilise pas le type char avec Unicode !
C'est peut-être là la source des désagréments.
Le type char c'est un type du C de -127 à 128 ( et unsigned de 0 à 255 ) .
Alors qu'Unicode a été crée pour supporter jusqu'à 65536 codes.
Utiliser TEXT , TCHAR ou autres mais pas char

Code:

---

1 2 3

MyFile->Write((void*)(buffer.GetBuffer(buffer.GetLength())),buffer.GetLength()); MyFile->Write((void*)(&endl),1);

---

Mieux vaut concaténer directement le "\0" dans buffer de type CString :
CString buffer ="chaine quelconque" + "\n" puis écrire avec CFile

ceci pourra peut-être être utile

:D

Citation:

---

Summary
All strings that are passed to and received from 32-bit OLE APIs and interface methods use Unicode. This requires applications that use ANSI strings to convert them to Unicode before passing them to OLE and to convert the Unicode strings that are received from OLE to ANSI. This article demonstrates how these conversions can be done.



More Information
Windows NT implements Unicode (or wide character) and ANSI versions of Win32 functions that take string parameters. However Windows 95 does not implement the Unicode version of most Win32 functions that take string parameters. Instead it implements only the ANSI versions of these functions.

A major exception to this rule is 32-bit OLE. 32-bit OLE APIs and interface methods on Windows NT and Windows 95 use Unicode exclusively. ANSI versions of these functions are not implemented either on Windows NT or Windows 95.

This means that a 32-bit application that needs to run on both Windows 95 and Windows NT must use the ANSI versions of the non-OLE Win32 functions and must convert ANSI strings to Unicode before they are passed to OLE.

A 32-bit Unicode application that runs only on Windows NT need not use any ANSI/Unicode conversion functions.

Win32 provides MultiByteToWideChar and WideCharToMultiByte to convert ANSI strings to Unicode and Unicode strings to ANSI. This article provides AnsiToUnicode and UnicodeToAnsi, which uses these functions for ANSI/Unicode conversion.

/*
* AnsiToUnicode converts the ANSI string pszA to a Unicode string
* and returns the Unicode string through ppszW. Space for the
* the converted string is allocated by AnsiToUnicode.
*/

HRESULT __fastcall AnsiToUnicode(LPCSTR pszA, LPOLESTR* ppszW)
{

ULONG cCharacters;
DWORD dwError;

// If input is null then just return the same.
if (NULL == pszA)
{
*ppszW = NULL;
return NOERROR;
}

// Determine number of wide characters to be allocated for the
// Unicode string.
cCharacters = strlen(pszA)+1;

// Use of the OLE allocator is required if the resultant Unicode
// string will be passed to another COM component and if that
// component will free it. Otherwise you can use your own allocator.
*ppszW = (LPOLESTR) CoTaskMemAlloc(cCharacters*2);
if (NULL == *ppszW)
return E_OUTOFMEMORY;

// Covert to Unicode.
if (0 == MultiByteToWideChar(CP_ACP, 0, pszA, cCharacters,
*ppszW, cCharacters))
{
dwError = GetLastError();
CoTaskMemFree(*ppszW);
*ppszW = NULL;
return HRESULT_FROM_WIN32(dwError);
}

return NOERROR;
/*
* UnicodeToAnsi converts the Unicode string pszW to an ANSI string
* and returns the ANSI string through ppszA. Space for the
* the converted string is allocated by UnicodeToAnsi.
*/

HRESULT __fastcall UnicodeToAnsi(LPCOLESTR pszW, LPSTR* ppszA)
{

ULONG cbAnsi, cCharacters;
DWORD dwError;

// If input is null then just return the same.
if (pszW == NULL)
{
*ppszA = NULL;
return NOERROR;
}

cCharacters = wcslen(pszW)+1;
// Determine number of bytes to be allocated for ANSI string. An
// ANSI string can have at most 2 bytes per character (for Double
// Byte Character Strings.)
cbAnsi = cCharacters*2;

// Use of the OLE allocator is not required because the resultant
// ANSI string will never be passed to another COM component. You
// can use your own allocator.
*ppszA = (LPSTR) CoTaskMemAlloc(cbAnsi);
if (NULL == *ppszA)
return E_OUTOFMEMORY;

// Convert to ANSI.
if (0 == WideCharToMultiByte(CP_ACP, 0, pszW, cCharacters, *ppszA,
cbAnsi, NULL, NULL))
{
dwError = GetLastError();
CoTaskMemFree(*ppszA);
*ppszA = NULL;
return HRESULT_FROM_WIN32(dwError);
}
return NOERROR;

}

---