Re: Window types
- From: "Joe Butler" <ffffh.no.spam@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 18 Sep 2005 21:25:58 +0100
"Robby" <Robby@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1A90744E-BFB5-49F6-A1C8-8E8AFDD96EF8@xxxxxxxxxxxxxxxx
> Hi,
#ifdef UNICODE
typedef WCHAR TCHAR, * PTCHAR;
typedef LPWSTR LPTCH, PTCH, PTSTR, LPTSTR;
typedef LPCWSTR LPCSTR;
#else
typedef char TCHAR, * PTCHAR;
typedef LPSTR LPTCH, PTCH, PTSTR. LPTSTR;
typedef LPCSTR LPCTSTR
#endif
> From what I read the above declaration creates a TCHAR as generic. And
then
> how does the TCHAR character definition fit in to all this:
>
> struct
> {
> int iIndex;
> TCHAR * szLable; //If UNICODE defined, shouldn't it mean WCHAR type?
> TCHAR * szDesc'
> }
>
Yes. Under a Unicode build (if you choose to build Unicode), szLabel and
szDec are both pointer to WCHARS (but you still call them TCHAR's). This is
only really important when you are trying to pass the pointers around. The
structure is still the same size (at least for a 32-bit compiler - i.e.
you're not trying to build for 64-bit Windows with a 64-bit compiler. I
think under 64-bit, the pointers will be double the size - but there might
be some techy stuff that means they are still 32-bit - I don't know.).
If the only text your app needs to deal with can be handled with ASCII
characters, then you don't need to define Unicode. That means that TCHAR
(if you use it instead of 'char') is a single byte character. So, if all
your code uses TCHARS instead of chars, everything is just fine, exactly the
same as if you had used 'char's instead and works as expected. If you also
use things like strlen(), etc. then everthing works as expected. What's the
point? It just makes it easier when you decide to build for Unicode later
on.
If now you decided to support, say Japanese via Unicode, you will need to
change all your code to be 2-byte characters (for 16-bit Unicode) - I think
you realise that there are just too many Japanese characters and symbols to
encode with only 8-bits. So, you will define UNICODE and _UNICODE, which
causes all your variables and pointers defined as TCHARS to now become
2-byte character strings and pointers to 2-byte characters, etc. Note, any
variable this is explicitly given as a 'char' will remain an 8-bit character
(which may be important in certain circumstances). So, your code will still
work with no other changes (because you used TCHAR thruout).... except that
if you _did_ use strlen(), etc. throughout your code. You would now be
passing strings that actually were made of 16-bit characters into functions
that are expecting 8-bit characters - so, actually things will just fall
apart and you app will either not compile or it would likely crash or
produce incomplete sentences on the screen due to strlen(), etc.
misinterpreting the string of data that was passed to it.
So, when writing your ASCII app (if you would later be interested in
building it as a Unicode app), any string manipulation function that you
call should be the generic version: e.g. _tcslen() instead of strlen() and
other suitable substitutions. Also your strings need to be defined with the
T or TEXT macros. Now, when you build you app as non-unicode, it will built
as if it were a plain ASCII app because all of the generic stuff
T"whatever", TCHAR, TCHAR *, etc. just being chars etc. When you build the
same app as Unicode, if all your text manipulation was generic it should
just work automatically as a unicode app because all of your generic TCHARS,
etc. are actually defined as 16-bit characters, etc.. So, if you had a
Japanese input method available (a Japanese keyboard or 'normal QWERTY'
keyboard with a bit of software that took groups of Roman letters such as
'ko' 'ni' 'chi' 'wa' and converted them into the appropriate Japanese
symbols), you'd be able to input, manipulate and save Japanese (and any
other Unicode character) in your app.
It's actually like a lot of Windows stuff. If you use the Windows types
defined in the headers, CHAR, UINT, etc. for interacting with the API you'll
have an easier time re-building your app when the next big windows comes
along. If you don't use the Windows types, then you're more likely to have
bigger issues with the next big Windows when you try to compile for it
because particular API functions are now taking a different datatype size
(e.g. 4-bytes instead of 2-bytes for a counter, etc.). If you used the
Windows defined types, then most of that gets modified in the headers, and
you don't have to deal with it.
> I am extremely confused, I have 7 C books and the only one that touches
this
> subject is Petzold's book,
Probably because that's the only one that is concerned with building ASCII
and Unicode apps under Windows.
and unfortunately excuse the expression (I am
> rattling my brains to try to get this from a 2 page explanation) I tried
> Google groups, I find there not even close to the active and skillfull
> response that MS news Groups renders. All the books I have talk about
basic
> char definitions such as:
>
> char string[256];
> char *title;
> and functions like putchar, toupper, atof, atol ....
>
> but nothing that explains things like this:
>
> typedef CHAR * PCHAR, * LPCH, * PCH, * NPSTR, * LPSTR, * PSTR;
That's probably because they are specific to the Windows environment that
you are developing under.
>
> and how to use them in windows.....
If an API function takes a CHAR, then define any variable you create that
will get passed to that API as a CHAR. Don't try to reverse engineer it and
work out that it is really a 'char'.
There are different types of Unicode if you really get into it. But I
wouldn't worry about that yet unless you are going to be saving or reading
Unicode files.
http://www.unicode.org/ Is the website, I think.
A bit of a long post, that I accept may not be what you wanted, so if you
have any specific questions that are not answered, please post them.
.
- References:
- Window types
- From: Robby
- Window types
- Prev by Date: Compiler cant find defined GUID
- Next by Date: Re: Compiler cant find defined GUID
- Previous by thread: Window types
- Next by thread: Re: Window types
- Index(es):
Relevant Pages
|
Loading
