From: Friedel Jantzen on
Hello Jean!

As Ulrich replied, you can simplify it all by setting the Unicode option in
your project, if you are using MSVC.
Other compilers may require your defines
#define UNICODE
#define _UNICODE
as the first lines of the first header;
if you do not use any header file, as the first lines of your c file.

Many names for the API functions are macros, and with UNICODE defined they
and the Windows structs are automatically set to the unicode versions.
This means: You need not write FindFirstFileW, FindFirstFile will mean the
same.
And these WideChar versions expect WCHAR string parameters:
To keep it easy, use WCHAR always, no conversions needed.

int how_many_fichiers_unicode(WCHAR *wrep) {

int nbFic=0;
WIN32_FIND_DATA wfind; // This is WIN32_FIND_DATAW
HANDLE hh = FindFirstFile(wrep, &wfind);
// use INVALID_HANDLE_VALUE!
// Search msdn for FindFirstFile
if(hh == (HANDLE)INVALID_HANDLE_VALUE) return -1;

do {
if(wfind.dwFileAttributes & (FILE_ATTRIBUTE_HIDDEN |
FILE_ATTRIBUTE_DIRECTORY)) continue;
nbFic++;
MessageBox(NULL, wfind.cFileName, L"Test", MB_OK); // This is
MessageBoxW
} while(FindNextFile(hh, &wfind));

FindClose(hh);
return nbFic;
}

Regards,
Friedel
From: Jean on
> if you are using MSVC
yes, i use MSVC6 and pure C SDK.
i set UNICODE in the project and got 34765 warnings :-))

using WCHAR is easy, thank you for the tip.
i suppose that i lust use _wsplitpath instead of _splitpath, swprintf
instead of wsprintf, wcscpy instead of strcpy etc... ?

Jean
"Friedel Jantzen" <nospam_plz(a)freenet.de> a �crit dans le message de news:
1tn9bakyzdgco$.wdsrvkl109j$.dlg(a)40tude.net...
> Hello Jean!
>
> As Ulrich replied, you can simplify it all by setting the Unicode option
> in
> your project, if you are using MSVC.
> Other compilers may require your defines
> #define UNICODE
> #define _UNICODE
> as the first lines of the first header;
> if you do not use any header file, as the first lines of your c file.
>
> Many names for the API functions are macros, and with UNICODE defined they
> and the Windows structs are automatically set to the unicode versions.
> This means: You need not write FindFirstFileW, FindFirstFile will mean the
> same.
> And these WideChar versions expect WCHAR string parameters:
> To keep it easy, use WCHAR always, no conversions needed.
>
> int how_many_fichiers_unicode(WCHAR *wrep) {
>
> int nbFic=0;
> WIN32_FIND_DATA wfind; // This is WIN32_FIND_DATAW
> HANDLE hh = FindFirstFile(wrep, &wfind);
> // use INVALID_HANDLE_VALUE!
> // Search msdn for FindFirstFile
> if(hh == (HANDLE)INVALID_HANDLE_VALUE) return -1;
>
> do {
> if(wfind.dwFileAttributes & (FILE_ATTRIBUTE_HIDDEN |
> FILE_ATTRIBUTE_DIRECTORY)) continue;
> nbFic++;
> MessageBox(NULL, wfind.cFileName, L"Test", MB_OK); // This is
> MessageBoxW
> } while(FindNextFile(hh, &wfind));
>
> FindClose(hh);
> return nbFic;
> }
>
> Regards,
> Friedel


From: Ulrich Eckhardt on
Jean wrote:
> I defined UNICODE because it did not want to modify all my program
> (several thousands of lines).
> I thought that i could use it in a small module just to read file names,
> then add these file names to a syslistview.

No, keep this thing consistent throughout all your code. If you want parts
of the code to use the wchar_t APIs, use them explicitly.

> Must i declare all my project as UNICODE and modify declarations such as
> char -> w_char, etc... ?

No, you got that backwards. UNICODE/_UNICODE don't affect the meaning of
char or wchar_t at all! The only thing they affect is TCHAR, which resolves
to char normally and to wchar_t when the macros are defined. Similarly, all
functions and types depending on TCHAR are affected, like e.g. LPCTSTR or
CreateFile.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

From: Jean on
OK, thank you

Jean
"Ulrich Eckhardt" <eckhardt(a)satorlaser.com> a �crit dans le message de news:
ham097-kgn.ln1(a)satorlaser.homedns.org...
> Jean wrote:
>> I defined UNICODE because it did not want to modify all my program
>> (several thousands of lines).
>> I thought that i could use it in a small module just to read file names,
>> then add these file names to a syslistview.
>
> No, keep this thing consistent throughout all your code. If you want parts
> of the code to use the wchar_t APIs, use them explicitly.
>
>> Must i declare all my project as UNICODE and modify declarations such as
>> char -> w_char, etc... ?
>
> No, you got that backwards. UNICODE/_UNICODE don't affect the meaning of
> char or wchar_t at all! The only thing they affect is TCHAR, which
> resolves
> to char normally and to wchar_t when the macros are defined. Similarly,
> all
> functions and types depending on TCHAR are affected, like e.g. LPCTSTR or
> CreateFile.
>
> Uli
>
> --
> Sator Laser GmbH
> Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932
>


From: r_z_aret on
On Thu, 08 Apr 2010 12:04:33 +0200, Ulrich Eckhardt
<eckhardt(a)satorlaser.com> wrote:

>Jean wrote:
>> I defined UNICODE because it did not want to modify all my program
>> (several thousands of lines).
>> I thought that i could use it in a small module just to read file names,
>> then add these file names to a syslistview.
>
>No, keep this thing consistent throughout all your code. If you want parts
>of the code to use the wchar_t APIs, use them explicitly.
>
>> Must i declare all my project as UNICODE and modify declarations such as
>> char -> w_char, etc... ?
>
>No, you got that backwards. UNICODE/_UNICODE don't affect the meaning of
>char or wchar_t at all! The only thing they affect is TCHAR, which resolves
>to char normally and to wchar_t when the macros are defined. Similarly, all
>functions and types depending on TCHAR are affected, like e.g. LPCTSTR or
>CreateFile.

UNICODE also affects definitions of macros used for function names. So
MessageBox is defined as MessageBoxW when UNICODE is defined, but
defined as MessageBoxA when UNICODE is not defined.

>
>Uli

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 400
Boston, MA 02116
www.penfact.com
Useful reading (be sure to read its disclaimer first):
http://catb.org/~esr/faqs/smart-questions.html