Unicode
-
I don't suppose there is an interest for a forum on Unicode is there? I'm asking 'cause I'm having one heck of a tough time trying to find information / explantions beyond what is presented at the Unicode.org site(basic newbie questions and such, especially related to VC++). :|
-
I don't suppose there is an interest for a forum on Unicode is there? I'm asking 'cause I'm having one heck of a tough time trying to find information / explantions beyond what is presented at the Unicode.org site(basic newbie questions and such, especially related to VC++). :|
Hi, I used UNICODE with VC++ about 99% of the time, so fire away here if you want, I may be able to help. :suss: Old Simon HB9DRV
-
Hi, I used UNICODE with VC++ about 99% of the time, so fire away here if you want, I may be able to help. :suss: Old Simon HB9DRV
Thank you sir, here goes... Oookay (sorry this is a little long winded), I have a project that was started waaaaaaay back in 1999 and left alone until recently. My job is to take this sucker and start to bring it into the Unicode world gradually by using the generic macros. The hardware that our program must communicate with is strictly 8-bit and we can't convert it to 16-bit. Not yet anyways. For test purposes I compile the program in _UNICODE and of course I get a lot of errors. Usually they are just "text" so I simply add a _T("text")and it fixed the problem. However, I am getting the odd error with a += which I'm not too sure about. Here's an example: m_csRecon += m_cbyMsgData.GetAt(i); // Error C2593 Operator += is ambiguous which is fixed by: m_csRecon += LPTSTR(m_cbyMsgData.GetAt(i)); m_csRecon is a CString m_cbyMsgData is a CByteArray Sorry for the silly question but how does a pointer simply solve the problem? And will this give me quirky results down the road? Should I convert m_cbyMsgData to a CWordArray instead? Can't it just add the byte to the 2-byte CString? Or did I just answer my question? :-O Pascal
-
Thank you sir, here goes... Oookay (sorry this is a little long winded), I have a project that was started waaaaaaay back in 1999 and left alone until recently. My job is to take this sucker and start to bring it into the Unicode world gradually by using the generic macros. The hardware that our program must communicate with is strictly 8-bit and we can't convert it to 16-bit. Not yet anyways. For test purposes I compile the program in _UNICODE and of course I get a lot of errors. Usually they are just "text" so I simply add a _T("text")and it fixed the problem. However, I am getting the odd error with a += which I'm not too sure about. Here's an example: m_csRecon += m_cbyMsgData.GetAt(i); // Error C2593 Operator += is ambiguous which is fixed by: m_csRecon += LPTSTR(m_cbyMsgData.GetAt(i)); m_csRecon is a CString m_cbyMsgData is a CByteArray Sorry for the silly question but how does a pointer simply solve the problem? And will this give me quirky results down the road? Should I convert m_cbyMsgData to a CWordArray instead? Can't it just add the byte to the 2-byte CString? Or did I just answer my question? :-O Pascal
Hi Pascal, Terminology: there are two types of string, UNICODE (wide, 16-bit) and multi-byte (default 8-bit). In UNICODE CString can load a multi-byte, for example:
char* pszMultiByte = "Simon is 8";
CString strUnicode(pszMultiByte); // Now held in UNICODESo if you have strings in a CByteArray you can load them into a CString, then just add the CStrings.
CByteArray abyData;
CString strFromArray((char*)abyData.GetData()); // Note use of cast.strUnicode += strFromArray;
To answer the question about the cast (where you use LPTSTR). This solves the ambiguity because you are telling the CString m_csRecon what type of data you are supplying, (and in your case it's going to go wrong I think). Without this, the compiler had more than one possible option, and is asking you for help (provide a cast). Casts are useful and dangerous - you can cast incorrectly, so watch out. I very strongly suggest that you use casts as I did with strFromArray((char*)abyData.GetData()) because that way you can see exactly what you are trying to do, it's also your note to yourself. If you supply a cast it will only work the way you intend, no default behaviour at all. I never rely on default conversion to UNICODE - I always cast everything. Also, I suggest you set VC++ to warning level 4 - this will pick up lots of areas where things may be going wrong. Based on what I understand about what you are doing: * Convert all incoming strings (held in the CByteArray) from char* to UNICODE in a CString or CStringArray. * Work with UNICODE internally. * Convery all outgoing strings from UNICODE (wide, 16 bit) to char* (multibyte) just before the vanish down the wire to the other side. There are routines in MSDN to do this. Look for wide to multi-byte. If you want to e-mail me directly do so using simon.brown@kns.ch and I'll help as I can. I only had 100,000 lines in my previous project when I had to convert to UNICODE, toook two long days. My advice is to alsways start in UNICODE, I do that except for some DLLs which talk to non-UNICODE targets such as Lotus Notes. Good Luck :rolleyes: Old Simon HB9DRV