asked on

Unicode characters act weirdly

I have a task to update some MFC COM-components to support Unicode characters (Chinese text). So far I have successfully fixed two components, so I kind of know what I'm doing. With the third component, I faced a problem where Chinese text displayd correctly on the component when it was written, but as soon as the user pressed enter or the text field otherwise lost focus, the characters changed to something completely wrong. This happened because I had both _MBCS and _UNICODE defined in the project and got fixed when I removed _MBCS. Now, with the fourth component I have the same problem but this time only _UNICODE is defined and I have no clue what causes this. In addition, the Chinese text displays correctly when it's first written to wordpad for example and then copy/pasted to component. Although this doesn't help since I have to use the component to send the Unicode text to another device and when we tested, the text is not sent correctly.

jhance

That a component would spontaneously change what it is displaying seems very unlikely. I suspect you have an event of some sort being triggered when the component looses focus that is changing the contents of what is displayed. I think you need to look deeper into your code and see what's going on when the component looses focus.

_ys_

Do you have any DDV_ rountines defined within your Dialog's DoDataExchange function.

Sounds like a custom DDV_ routine may be the culprit.

williamcampbell

are you using TCHARS or OLECHARS or wchar_t's or BSTRS's ?

milzer

ASKER

Actually, could these conversions be the source of this problem? This is done in killfocus, but it's called also when text is copy/pasted so I doubt that this causes the problem.

-----
CString str;
WCHAR temp_str[20];
BSTR bstrTempStr = NULL;

m_Edit.GetWindowText(bstrTempStr);
swprintf (temp_str, L"%s", bstrTempStr);
str.Format(_T("%ls"),temp_str);
-----

For jhance and _ys_: I didn't find any events or handlers that could cause this.
And for williamcampbell: There's TCHAR's, wchar's and BSTR's used in code, the component is done by some other guy about a year ago and I'm just a poor guy fixing it :)

_ys_

>> m_Edit.GetWindowText(bstrTempStr);
CWnd::GetWindowText doesn't even have a function that takes a BSTR as an argument.

If the ultimate goal is to store the text into a CString then:

CString str;
m_Edit.GetWindowText(str);

will simply do the desired job.

williamcampbell

my suggestion find all occurances of BSTR and replace them with _bstr_t BSTR's are usually used for COM stuff.

otherwise as _ys_ suggests do all your string handling with CString

milzer

ASKER

This is a COM component (as I said in my question already) so I have to use BSTR's. And the GetWindowText here doesn't accept CString parameter.

GroupListControl.cpp(1860) : error C2664: 'int __thiscall ATL::CWindow::GetWindowTextW(unsigned short ** )' : cannot convert parameter 1 from 'class WTL::CString' to 'unsigned short ** '

..I'm losing my hope with this :/

_ys_

> And the GetWindowText here doesn't accept CString parameter.
Apologies. I has assumed the use of MFC, as opposed to their ATL variants.

CString str;
TCHAR temp_str[20];

m_Edit.GetWindowText(&temp_str, 20);
str.Format(_T("%ls"),temp_str);

I've eliminated the intermediate BSTR as it was causing problems. This may not even be the cause of your problems, but at least the code is cleaner.

milzer

ASKER

I still didn't found any reason for this, but when we finally got actual Chinese Windows and tested with it, the component worked just fine. With English Windows and Chinese localisations it didn't work.

ASKER CERTIFIED SOLUTION

DarthMod

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial