How to LPCTSTR Convert to char *
in [MFC]
|
Prev: why is CoUninitialize being called in CDHtmlDialog::Navigate
Next: A little help with a LNK2019 error?
From: Joseph M. Newcomer on 6 Dec 2006 13:26 I would have suggested T2A, but the question was so badly phrased that I wanted to see more of an explanation of what was intended. joe On Tue, 05 Dec 2006 22:37:58 -0800, "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote: >"Tom Serface" <tserface(a)msn.com> wrote in >news:uRy8wWPGHHA.1804(a)TK2MSFTNGP02.phx.gbl: > >> Well a lot depends on how your project was compiled. If you compiled >> non-Unicode then you won't have to convert really since the "T" will >already >> compile as "char" rather than "wchar_t". If you are using Unicode you can >> use WideCharToMultiByte() to convert. >> >> In either case the first is a const and the second, not so you will have to >> be careful how you use it. You could just assign either to a CString. If >> you assign to CStringW it will convert char * to wchar_t and if you assign >> to CStringA it will do the opposite. It's kind of handy, but you have to >be >> careful how you use it. > >Or "the easy way": T2A >(with the warning that you might loose data). Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: r norman on 6 Dec 2006 14:01 On Wed, 06 Dec 2006 13:12:20 -0500, Joseph M. Newcomer <newcomer(a)flounder.com> wrote: >An LPCTSTR is a const TCHAR *, so do you mean you want to remove the const attribute, or >you really want a 'char *' data type (remember that char and char* represent an obsolete >technology that should be used only in very rare and exotic situations where you are >absolutely guarnteed because of external specs to be using 8-bit characters, and should >never be coded as a matter of course in any program). > >If you really want a 'char *', that is, a pointer to an 8-bit character string, then you >have to explain why you need it and how you plan to handle the down-conversion from >Unicode characters that have no 8-bit equivalents. There are those of us who must interface with external hardware in which the communication interface specifies ASCII character set messages. For us, creating char[] messages and filling specific fields with char strings is quite essential. I was enormously taken aback by switching to the latest Visual Studio and finding all my strings defaulting to Unicode. So far my applications do not need internationalization and I am working hard to separate strings used for user interface from strings used for device communications, though they are closely inter-related. Still, legacy code including pieces dating back to DOS days, makes for hard work which is hard to get somebody to pay for since it does not produce visible enhancements to performance or add features.
From: Ajay Kalra on 6 Dec 2006 14:18 r norman wrote: > On Wed, 06 Dec 2006 13:12:20 -0500, Joseph M. Newcomer > <newcomer(a)flounder.com> wrote: > > >An LPCTSTR is a const TCHAR *, so do you mean you want to remove the const attribute, or > >you really want a 'char *' data type (remember that char and char* represent an obsolete > >technology that should be used only in very rare and exotic situations where you are > >absolutely guarnteed because of external specs to be using 8-bit characters, and should > >never be coded as a matter of course in any program). > > > >If you really want a 'char *', that is, a pointer to an 8-bit character string, then you > >have to explain why you need it and how you plan to handle the down-conversion from > >Unicode characters that have no 8-bit equivalents. > > There are those of us who must interface with external hardware in > which the communication interface specifies ASCII character set > messages. For us, creating char[] messages and filling specific > fields with char strings is quite essential. I was enormously taken > aback by switching to the latest Visual Studio and finding all my > strings defaulting to Unicode. You dont need to have it in UNICODE. You can make it all MBCS as well. If you migrated projects from earlier versions, these projects would stay MBCS. We have been using MBCS and it works fine. >So far my applications do not need > internationalization and I am working hard to separate strings used > for user interface from strings used for device communications, though > they are closely inter-related. Still, legacy code including pieces > dating back to DOS days, makes for hard work which is hard to get > somebody to pay for since it does not produce visible enhancements to > performance or add features. It does not look like you need UNICODE. --- Ajay
From: Tom Serface on 6 Dec 2006 16:14 I agree with Ajay... I would just change it to an ANSI project by turning Unicode off in the Project Properties. That will be the easiest solution since you have no internationalization needs. Tom "r norman" <r_s_norman@_comcast.net> wrote in message news:4e4en21dq26inbns39jaeq5ngk7ekvborc(a)4ax.com... > On Wed, 06 Dec 2006 13:12:20 -0500, Joseph M. Newcomer > <newcomer(a)flounder.com> wrote: > >>An LPCTSTR is a const TCHAR *, so do you mean you want to remove the const >>attribute, or >>you really want a 'char *' data type (remember that char and char* >>represent an obsolete >>technology that should be used only in very rare and exotic situations >>where you are >>absolutely guarnteed because of external specs to be using 8-bit >>characters, and should >>never be coded as a matter of course in any program). >> >>If you really want a 'char *', that is, a pointer to an 8-bit character >>string, then you >>have to explain why you need it and how you plan to handle the >>down-conversion from >>Unicode characters that have no 8-bit equivalents. > > There are those of us who must interface with external hardware in > which the communication interface specifies ASCII character set > messages. For us, creating char[] messages and filling specific > fields with char strings is quite essential. I was enormously taken > aback by switching to the latest Visual Studio and finding all my > strings defaulting to Unicode. So far my applications do not need > internationalization and I am working hard to separate strings used > for user interface from strings used for device communications, though > they are closely inter-related. Still, legacy code including pieces > dating back to DOS days, makes for hard work which is hard to get > somebody to pay for since it does not produce visible enhancements to > performance or add features. >
From: r norman on 6 Dec 2006 16:19
On Wed, 6 Dec 2006 13:14:18 -0800, "Tom Serface" <tserface(a)msn.com> wrote: >I agree with Ajay... I would just change it to an ANSI project by turning >Unicode off in the Project Properties. That will be the easiest solution >since you have no internationalization needs. > That is actually what I do. But I am also trying to be "forward looking" and "modern", not to mention anticipating having to deal with the need to interface with Unicode systems soon, now. |