Using TCHAR and char array
-
You should zero-terminate the string, I suppose, i.e.
array[6] = 0
array[7] = 0:) Nevermind, I was a it hasty. :-O
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]modified on Thursday, October 8, 2009 1:55 PM
-
You should zero-terminate the string, I suppose, i.e.
array[6] = 0
array[7] = 0:) Nevermind, I was a it hasty. :-O
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]modified on Thursday, October 8, 2009 1:55 PM
-
Not quite, he's sending a char* which gets filled with TCHARs. It's the old Unicode <--> ASCII confusion again! Do people not read the manuals anymore?
-
When i try to write the "array" string into a file, all that it writes is "A", and its ignoring the remaining array indexes. Can this be solved by null terminating? How to do that?
dipuks wrote:
Can this be solved by null terminating?
The short answer is, no! You need to understand the difference between TCHAR (Unicode, 16 bit) and ASCII (8-bit) characters. You cannot store a TCHAR string into a char[] array and expect the program to make sense of it. From the small piece of code you posted you just need to define your array as TCHAR[] and use the appropriate function calls to process the text. Take a look here in MSDN[^] for some more information.
-
Hi I have an API function call that asks to send a TCHAR* as an argument and it will return a string on the TCHAR* Instead of sending a TCHAR* i send it as a char array, like this char array[12]; Now when i debug and look at it, i see array[0] = A array[1] = 0 array[2] = B array[3] = 0 array[4] = C array[5] = 0 So if am expecting an output string of "ABC". What am seeing is, everyother index in the array is set to "0". Why's this happening? Is it a problem with using char array in place of TCHAR? How to use the TCHAR?
Hi, You are doing an Unicode build (have defined
_UNICODEinstead of_MBCS) and thereforeTCHARbehaves likewchar_t(double byte character). The API is obviously returning an Unicode string to you, and you have accepted it into an ANSI style string. The Unicode version of the API was called, because you are doing an Unicode build. To solve this, you could do an MBCS build. However, I strongly recommend the usage ofTCHARinstead ofcharand use neutral string manipulation functions and APIs - for example,_tcscpyinstead of strcpy._tcscpywill behave likestrcpywhen you do an MBCS build and will behave likewcscpywhen you do an Unicode build. This way, you could do an Unicode build and an MBCS build without making changes in the source code. Take a look at the "Windows Data types" section of this article[^]. I would also recommend this two part article to you: The Complete Guide to C++ Strings, Part I - Win32 Character Encodings[^] The Complete Guide to C++ Strings, Part II - String Wrapper Classes[^]It is a crappy thing, but it's life -^ Carlo Pallini
-
dipuks wrote:
Can this be solved by null terminating?
The short answer is, no! You need to understand the difference between TCHAR (Unicode, 16 bit) and ASCII (8-bit) characters. You cannot store a TCHAR string into a char[] array and expect the program to make sense of it. From the small piece of code you posted you just need to define your array as TCHAR[] and use the appropriate function calls to process the text. Take a look here in MSDN[^] for some more information.
Richard MacCutchan wrote:
You need to understand the difference between TCHAR (Unicode, 16 bit) and ASCII (8-bit) characters.
TCHARis not an Unicode character.TCHARis defined either as an Unicode character (wchar_t) or an ASCII character (char), depending on the build.It is a crappy thing, but it's life -^ Carlo Pallini
-
Richard MacCutchan wrote:
You need to understand the difference between TCHAR (Unicode, 16 bit) and ASCII (8-bit) characters.
TCHARis not an Unicode character.TCHARis defined either as an Unicode character (wchar_t) or an ASCII character (char), depending on the build.It is a crappy thing, but it's life -^ Carlo Pallini
-
Not quite, he's sending a char* which gets filled with TCHARs. It's the old Unicode <--> ASCII confusion again! Do people not read the manuals anymore?
You're right, of course. Too much drugz, today... :rolleyes: :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Hi, You are doing an Unicode build (have defined
_UNICODEinstead of_MBCS) and thereforeTCHARbehaves likewchar_t(double byte character). The API is obviously returning an Unicode string to you, and you have accepted it into an ANSI style string. The Unicode version of the API was called, because you are doing an Unicode build. To solve this, you could do an MBCS build. However, I strongly recommend the usage ofTCHARinstead ofcharand use neutral string manipulation functions and APIs - for example,_tcscpyinstead of strcpy._tcscpywill behave likestrcpywhen you do an MBCS build and will behave likewcscpywhen you do an Unicode build. This way, you could do an Unicode build and an MBCS build without making changes in the source code. Take a look at the "Windows Data types" section of this article[^]. I would also recommend this two part article to you: The Complete Guide to C++ Strings, Part I - Win32 Character Encodings[^] The Complete Guide to C++ Strings, Part II - String Wrapper Classes[^]It is a crappy thing, but it's life -^ Carlo Pallini
-
You're right, of course. Too much drugz, today... :rolleyes: :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]