tchar or just char

what char types do you use in winapi programming? i have both petzold and programming windows from the ground up. petzold uses tchar (for unicodes, i think) and from the ground up just uses char with the stdio and string.h and the sort.

what is best? what do you prefer?

thanks.

TCHAR....not for the reason for a pure UNICODE build...as 98/ME are still so in use....but one day, those platforms will be gone.....and getting used to unicode as well as being happy using the typedef'ed string functions that TCHAR.H offers will make the change un-noticable

but, say you're getting input from a text box, do you just get it in tchar form? or char?

When you #define UNICODE then TCHAR resolves to type wchar_t (unsigned short). When UNICODE is not #defined TCHAR resolves to type char. You use _T or TEXT macros to ensure the correct type as these macros are defined differently depending on whether or not UNICODE is #defined.

Under win2k/xp the native/default is to use UNICODE (wide chars) and the os will internally convert any type char that you use. Under win9x the native/default is to use non-UNICODE (ie char) and they can get very upset if you try to use wide character strings except with a very few wide char functions, such as MessageBoxW, with it.

If you look through your windows headers you will find that for most winapi fns there are two forms of each fn declared, an 'A' (for ANSI) and 'W' (for wide ) eg MessageBoxA and MessageBoxW. The fn that gets called depends entirely on whether or not UNICODE has been #defined.

So if you use TCHAR for all string types and don't #define UNICODE then all strings will be of type char and the 'A' form of the api fns will be utilised/called. If you do #define UNICODE then your TCHAR's will be of type wchar_t and the 'W' form of the api fns will be utilised/called.

So always use TCHAR and the _T or TEXT macros on all explicit strings; strings returned from eg GetWindowText (for your edit control example) will be returned as char from GetWindowTextA and as wchar_t from GetWindowTextW (UNICODE #defined).

The other preprocessor define of note is _UNICODE, which is only required if you need to use the string mapping macros declared in tchar.h to ensure UNICODE compliance when building apps using 'c' string fns. #defining _UNICODE and #including tchar.h and using the string mapping macros makes this possible to write code that can be compiled for either ANSI or UNICODE (but only if you need use 'c' string fns).

As a last note, use -DUNICODE to globally define UNICODE for a project rather than using #define in every file. Resorting to using it in every file that needs it becomes tedious at best, error-prone at worst and usually nightmarish for multi-file projects. If you compile from the command line, -DUNICODE, is good for just about everything (-D_UNICODE too, if you need it) - bcc5.5, mingw - but for msvc you may prefer to add UNICODE to 'Project->Setting->C++ tab, 'preprocessor settings' edit field.

Hope that helps. :)

but what if you, say, read a text file. how would you specify to read in tchar type intstead of the char type? and if windows internally converts if necessary, why would we the programmers need to work with this in such depth?

>>but what if you, say, read a text file. how would you specify to read in tchar type intstead of the char type? <<

IsTextUnicode

>>and if windows internally converts if necessary, why would we the programmers need to work with this in such depth?<<

This has already been answered. For more information look here.