


On analysing the data of str.m_pchdata is

Memcpy(widechar,str.m_pchD ata,str.Ge tLength()) It displayed the properdata in japanese character.įor getting the wide character I used it get it directly from cstring. Then I copied some japanesed string in the cedit box. and i created one member variable for that(control varaible not a cstring) I have created one dialog based application. It's working fine for me for simple cedit control.

I don't know why you are finding problem. I believe there may be a way around this be overriding something in CWnd but I have no idea how. I have the source code but there is a lot of code (in Cwnd, CEdit and the class derived from CEdit) that I would have to duplicate and convert to API calls. The obvious solution is to use API calls and avoid MFC altogether but the edit control I am using is deep within a library (grid control). There is obviously something in CWnd causing this as it happens for any CWnd object not just CEdit. I can put Unicode text into the control with ::SetWindowTextW or by manually pasting into the control from the clipboard but whenever I call ::GetWindowTextW all wide characters get converted to a question mark (?).Īfter months of experimenting (on and off) I have found that a window created with API calls work fine (ie ::GetWindowTextW works fine) but as soon as I call CWnd::SubclassWindow on it it stops working. If I create an edit control using API calls then calling ::GetWindowTextW works fine, but for an edit control created with MFC (CEdit) ::GetWindowTextW does not work. However under NT family I want to allow the user to enter a Unicode string. I have a program built for ANSI character set, not Unicode (since it needs to run under Win9x).
