Unicode in edit window

[jj2007]

Reviving an old thread:

If I create a window handle using CreateWindowExW not CreateWindowExA does anyone know if I can then send a
SendMessageW(handle,WM_GETTEXT,xx,buffer_pointer) to get the data, once the user has tabbed away from it.

I have tried that:

Code Select Expand

invoke CreateWindowExW, WS_EX_CLIENTEDGE, wChr$("edit"), NULL,
WS_CHILD or WS_VISIBLE or WS_BORDER\
or ES_LEFT or ES_AUTOHSCROLL or ES_MULTILINE, 0, 0, 0, 0,
hWnd, IdEdit, hInstance, NULL
mov hEdit, eax ; we have created a Unicode edit window


It works like a charm, I can even get text out of it with GetWindowTextW and display that text in a MessageBoxW. Except if the text is Unicode, i.e. I can paste a Russian or Arabic text into that edit window, it displays correctly, but when I call GetWindowTextW, I get the well-known ???????? stuff. To say something positive: the ??? arrive in Unicode as 3F 00 3F 00 etc

Hey Microsoft, didn't you switch to Unicode ages ago...?

Edit: I found the culprit. Naughty M$ :naughty:

[sinsi]

What is supposed to happen? I see russian/arabic in the edit, the msgbox shows the same, copy/paste shows the same...

[Farabi]

DId you not should use "RichEdit20W" for the class name in order to use Unicode?

[Antariy]

jj
You don't subclass the edit?
If you have using SetWindowLongA, to do this, then it is reason to "??????". Because windows thunks unicode-to-ascii-to-unicode, and drop non ANSI chars to ????.

Use SendMessageW,hwndEdit,WM_GETTEXT,sizeOfBufferInChars,ptrToBuffer

sizeOfBufferInChars - not in bytes, in chars. Buffer must have length (text length * 2 for Unicode) in bytes.

[Antariy]

jj
Note: I'm Russian :), but live in Asia.

[Antariy]

jj

I test your app - it show and russian, and arabics text.

Alex

[jj2007]

@Sinsi: What you see. It's fine now...
@Farabi: RichEd is not needed, an ordinary editbox must handle Unicode, too.
@Alex: Compliments! You must be pretty good in Windows if you knew that. I had googled a lot, didn't find anything, and stumbled by accident over this bloody SetWindowLongW problem. Now I wonder why M$ doesn't insist that we use SetFocusW ::)
By the way: My Russian is nil nowadays - I have copied that text from some website and hope it does not say anything offensive. If yes, please tell me so that I can remove it.

Anyway, the new MasmBasic version is quite happy with this snippet in the WM_CREATE handler:

Code Select Expand

invoke CreateWindowExW, WS_EX_CLIENTEDGE, wChr$("edit"), NULL,
WS_CHILD or WS_VISIBLE or WS_BORDER\
or ES_LEFT or ES_MULTILINE, 0, 0, 0, 0,
hWnd, IdEdit, hInstance, NULL
mov hEdit, eax ; we have created a Unicode edit window
invoke SetFocus, hEdit ; give the focus to the edit window
invoke SetWindowLongW, hEdit, ; we subclass the edit control
GWL_WNDPROC, SubEdit
mov opSubClass, eax ; the old pointer
; we use resource strings to fill the editbox:
wSetWin$ hEdit=wRes$(103)+wCrLf$+wCrLf$+wRes$(102)


[Antariy]

Hi, Jochen

Today evening, I disassebly yours wWinTest.exe app and find what may happen with non-ACP text.
You will subclass the edit window, and you make this right, but, in subclassing proc, you call the CallWindowProcA API! You will need to call the CallWindowProcW API instead this!!!

And, one sentence: in XP your app is work properly... You have Windows Vista or Seven installed?
As far as I know, MS introduce some changes in language and text conversion support in these systems.
For example, some "surprises" can be with encodings in WinXP, if manifest (for uxtheme) used.
I think, MS change something in thunking mechanism of windows subclassing in Vista+. Because, in winxp, uxtheme.dll may be unloaded by app at run-time, and, if app don't contain a manifest, it work, and all windows (edit, scrollbar, combobox etc.) is without theming (looking as Win9x). But in Vista, if app unload uxtheme - it crashes. So, theming is inalienable part of windows messaging engine => mechanism of thunking of unicode-ascii-unicode was changed in Vista+.

If you find fix for this already, then sorry for untimely help... I have online in ~21:00 by Greenwich (~22:00 in Rome). ??? I entangle in time zones :), may be, in 23:00 by your location time, Jochen.

I will attach to my post one my small app (archive "AxMsgTblViewer.zip"). It works on WinAll (tested on 98,2000,XP,Seven x64). It subclass almost all controls, and it have a manifest.
I write it for a good mood, but, without motivation, this pester to me very quickly :) So, its code 50/50 of beautiful/awesome :)
This app shows string or message from modules, by ID. So, it can show Win32 subsystem error-descriptions, native-subsys NTSTATUS-code description. And, if manual selection mode is on, you can add or drag'n'drop any Win32 executable/dll to the list, and see message/string by ID.
Algo of finding message/string by id - written by me (and not beauteful, but no reason to rewriting it). I simple investigated the format of MessageTable resource, and rev.-eng. the string-finding algo of Windows...

App is with MUI support, and now "speak" in English and Russian.

All code in this program is my own. And, for numbering-edit control used my procs for text(hex)-to-dword conversion. Those procs which I already attach to another post "http://www.masm32.com/board/index.php?board=6;topic=14438.0#msg115658". My second post in thread.
May be, it be useful for some peoples, that have some problems with subclassing of windows and using of manifest.
Callbacks are welcomed.

Alex

P.S.

You really expect help from hitting F1?
Go and find VK_F1 in the source!

Jochen, I find VK_F1, in disasm, in subclass of edit, in WM_KEYUP branch. What prize I can have? :)

[Antariy]

@Alex: Compliments! You must be pretty good in Windows if you knew that. I had googled a lot, didn't find anything, and stumbled by accident over this bloody SetWindowLongW problem. Now I wonder why M$ doesn't insist that we use SetFocusW

Yes, I have "some" experience in Windows GUI programming too, not only system programming :)

By the way: My Russian is nil nowadays - I have copied that text from some website and hope it does not say anything offensive. If yes, please tell me so that I can remove it.

No, it not say offensive things. But this text, hm.... - senseless.

А - russian letter "A".

[jj2007]

You will subclass the edit window, and you make this right, but, in subclassing proc, you call the CallWindowProcA API! You will need to call the CallWindowProcW API instead this!!!

Hi Alex,
Apparently, at least under Win XP, both versions show identical behaviour. As I wrote earlier, I would not be surprised if M$ asked us to use SetFocusW for Unicode controls, but it seems common sense prevailed. After all, when you use CreateWindowExW, Windows "knows" that this is a Unicode control, and can decide to use CallWindowProcW.

P.S.

You really expect help from hitting F1?
Go and find VK_F1 in the source!

Jochen, I find VK_F1, in disasm, in subclass of edit, in WM_KEYUP branch. What prize I can have? :)

Hmmm.... you can choose between icecream and beer (or red wine when it's getting cooler here). Come and pick your prize :toothy

[Antariy]

Hi Alex,
Apparently, at least under Win XP, both versions show identical behaviour. As I wrote earlier, I would not be surprised if M$ asked us to use SetFocusW for Unicode controls, but it seems common sense prevailed. After all, when you use CreateWindowExW, Windows "knows" that this is a Unicode control, and can decide to use CallWindowProcW.

If you set wndproc via SetWindowLongA, then, even call to CallWindowProcA or CallWindowProcW - no-ACP chars will be dropped :(
Windows "knows" about "Unicodeless" of control, but it work in not good way, as generally :) Joke. Because text must be passed via ASCII (also called ANSI) wndproc - it must be converted to ASCII. No other ways. So, programmer must choose between fully-unicoded app (i.e. CreateWindowExW and SetWindowLongW and CallWindowProcW), or must make universal solution - how I try make this in AxMsgTableViewer. On Unicode systems (all NTs) it work with Unicode, on 9x (ASCII-ANSI) - it work with ASCII. Don't beautiful solution, but no other way to create portable (Win9x-NT) app with support of Unicode.

Thunking mechanic is too complicated for posts, I know this - because I write multilingual apps also. And I don't good "speaker" in English :(

Hmmm.... you can choose between icecream and beer (or red wine when it's getting cooler here). Come and pick your prize.

I choose red wine :) Save it up to my coming. I come... afoot :)

Good night, Jochen.

[jj2007]

no-ACP chars will be dropped :(

Not sure what you mean. The control accepts Unicode, but Ansi as well. Click on Sayhi to see...

P.S.: I also added a Replace$() example. I had completely forgotten that MasmBasic included this function. Old age, I suppose.

[Antariy]

no-ACP chars will be dropped :(

Not sure what you mean. The control accepts Unicode, but Ansi as well. Click on Sayhi to see...

I very bad speaker in English. I mean, what, if Unicode window is subclassed via SetWindowLongA, then, even SetWindowTextA or SetWindowTextW or GetWindowTextA or GetWindowTextW used, chars, which don't correspond to system codepage (invoke GetACP), will be dropped to "?".

[hutch--]

It sometime has a bit to do with the fonts you have loaded, I keep the complete set of east asian fonts so I can access pages in Chinese and Japanese. You get Korean and Thai for free.

I have a "for internl use only" rich edit editor that accepts unicode characters and it happily displays, edits and saves Japanese characters.

[Antariy]

It sometime has a bit to do with the fonts you have loaded, I keep the complete set of east asian fonts so I can access pages in Chinese and Japanese. You get Korean and Thai for free.

Yes, you right Steve.

And you can find in MS Office installation the "Arial Unicode MS" font (it not installed without promting - need to "say" to install it). This font contain all chars of Unicode rev.1.1, and have size >20 MB(!!!)

Alex