ListView in-place edit box not showing correct Unicode character when typed

Question

ListView in-place edit box not showing correct Unicode character when typed

David H 0

Issue Description

When using an ANSI application that uses the UTF-8 code page, typing a non-ASCII character into a ListView's in-place edit box will result in nonsense characters being entered.

I have observed this by using a UK keyboard and attempting to enter the pound sign by typing Shift+3, or by using the Alt code Alt+0163. This can also be seen by using any other Alt code such as the example below.

Examples of entering pound sign (Alt+0163) and y with diaeresis (Alt+0255)

Here is a sample program that demonstrates this issue for your reference: ListViewEditTestWindow Compile it as ANSI in 32 bit (x86) mode.

The bug only happens when the Edit control is subclassed (after obtaining the HWND handle from the LVN_BEGINLABELEDIT notification) by using the older way of subclassing using SetWindowLongPtr with GWLP_WNDPROC.

I have observed that in these cases, two WM_CHAR messages are sent to the Edit control where the wParam contains the UTF-8 bytes of the character. In the pound example, the bytes are 0xA3 and 0xC2. They seem to be in reverse order though, so the first byte comes second.

This behaviour is not observed when using an Edit control in a regular window. It seems to be only when doing an in-place edit on a ListView (perhaps also TreeView but I didn't test that).

This bug is similar to another one I reported a while ago that affects combo boxes.

Versions Tested

Windows 10 Pro 22H2
Windows 11 Pro 22H2

Workarounds

Avoid subclassing the Edit control. Though this is not always possible as one may wish to recieve window messages from the control.
Use the newer SetWindowSubclass method of subclassing.

David H 0 Reputation points

2025-04-08T23:24:56.06+00:00

The ListView in my app is owner drawn, and it has extra space on the left for additional icons, which means the text in the column needs to be shifted right by some amount.

I therefore need to subclass the Edit control so I can receive WM_WINDOWPOSCHANGING messages and adjust the position of the control (just moving it once is not enough).

If there was a way to achieve this in a different way then I would not need to subclass and could avoid this bug.
RLWA32 48,416 Reputation points

2025-04-12T13:53:43.8633333+00:00

On Win10 22H2 I noticed that even when building for ANSI the edit control created by a ListView for in-place label editing always has a UNICODE window procedure. Would specifically using SetWindowLongPtrW for subclassing make a difference in your tests?
David H 0 Reputation points

2025-04-17T22:45:11.1133333+00:00

Hey, that works! At least in the example app. I've yet to try it in my real app, but hopefully it works there too.
RLWA32 48,416 Reputation points

2025-04-18T00:46:49.9866667+00:00

Hey, that works!

That's encouraging. Let us know how things go when you try it in your real application.
David H 0 Reputation points

2025-04-22T03:31:40.24+00:00

Turns out to be a bit trickier in my application.

When I subclass the way you mentioned, the text in the edit control gets truncated to just the first character. I traced that to the fact that I am calling SetWindowTextA after subclassing (in the LVN_BEGINLABELEDIT handler). If I omit that then it works, but I can't do that because, well I'll let the comment in my app's code explain:

By default, Windows will use the text of the first column, which may not be the primary one (for example, if the user has set the 'Id' column first and 'Name' second).

When I try to mimic this in my example application, it works fine. I'm not sure why.I tried instead calling SetWindowTextW (with a UTF-16 string) in my app, but the problem still happens. Then I decided to try passing an ASCII string to the W function and surprisingly that worked!

So I guess there is a Windows bug that is incorrectly interpreting ASCII strings as Unicode.

But there is also another problem now. When accepting the edit (i.e. typing something into the edit control and pressing Enter), the application gets garbage text. For example, if I type "test" then I get back "整瑳" as UTF-8. These are the Unicode characters (U+6574, U+7473), which is just the bytes for "test" (0x74, 0x65, 0x73, 0x74). Probably the same bug.
David H 0 Reputation points

2025-04-22T04:59:28.1166667+00:00

Given that my example app does nothing in it's window proc for the edit control, I'm guessing that is the difference. I don't have access to the source code for my application's window proc though, so I am not able to make modifications there (if I did, I'd use the newer SetWindowSubclass method).

So a bit more info about my application. When it subclasses the control, it gets the window proc of the main application (which is set when registering the window class) by calling GetClassInfoA and passing the returned lpfnWndProc member to SetWindowLongA.
When I did what you suggested and changed that to SetWindowLongW then I got the problems above. If I also use GetClassInfoW then those problems are not present, but also the original bug comes back.
RLWA32 48,416 Reputation points

2025-04-22T07:14:56.3466667+00:00

Thanks the follow-up. Well, it looks like Microsoft continues to have good reason to identify the setting to use UTF-8 as the active system code page as Beta.

1 answer

Your answer

David H 0 Reputation points

2025-04-08T23:24:56.06+00:00

The ListView in my app is owner drawn, and it has extra space on the left for additional icons, which means the text in the column needs to be shifted right by some amount.

I therefore need to subclass the Edit control so I can receive WM_WINDOWPOSCHANGING messages and adjust the position of the control (just moving it once is not enough).

If there was a way to achieve this in a different way then I would not need to subclass and could avoid this bug.
RLWA32 48,416 Reputation points

2025-04-12T13:53:43.8633333+00:00

On Win10 22H2 I noticed that even when building for ANSI the edit control created by a ListView for in-place label editing always has a UNICODE window procedure. Would specifically using SetWindowLongPtrW for subclassing make a difference in your tests?
David H 0 Reputation points

2025-04-17T22:45:11.1133333+00:00

Hey, that works! At least in the example app. I've yet to try it in my real app, but hopefully it works there too.
RLWA32 48,416 Reputation points

2025-04-18T00:46:49.9866667+00:00

Hey, that works!

That's encouraging. Let us know how things go when you try it in your real application.
David H 0 Reputation points

2025-04-22T03:31:40.24+00:00

Turns out to be a bit trickier in my application.

When I subclass the way you mentioned, the text in the edit control gets truncated to just the first character. I traced that to the fact that I am calling SetWindowTextA after subclassing (in the LVN_BEGINLABELEDIT handler). If I omit that then it works, but I can't do that because, well I'll let the comment in my app's code explain:

By default, Windows will use the text of the first column, which may not be the primary one (for example, if the user has set the 'Id' column first and 'Name' second).

When I try to mimic this in my example application, it works fine. I'm not sure why.I tried instead calling SetWindowTextW (with a UTF-16 string) in my app, but the problem still happens. Then I decided to try passing an ASCII string to the W function and surprisingly that worked!

So I guess there is a Windows bug that is incorrectly interpreting ASCII strings as Unicode.

But there is also another problem now. When accepting the edit (i.e. typing something into the edit control and pressing Enter), the application gets garbage text. For example, if I type "test" then I get back "整瑳" as UTF-8. These are the Unicode characters (U+6574, U+7473), which is just the bytes for "test" (0x74, 0x65, 0x73, 0x74). Probably the same bug.
David H 0 Reputation points

2025-04-22T04:59:28.1166667+00:00

Given that my example app does nothing in it's window proc for the edit control, I'm guessing that is the difference. I don't have access to the source code for my application's window proc though, so I am not able to make modifications there (if I did, I'd use the newer SetWindowSubclass method).

So a bit more info about my application. When it subclasses the control, it gets the window proc of the main application (which is set when registering the window class) by calling GetClassInfoA and passing the returned lpfnWndProc member to SetWindowLongA.
When I did what you suggested and changed that to SetWindowLongW then I got the problems above. If I also use GetClassInfoW then those problems are not present, but also the original bug comes back.
RLWA32 48,416 Reputation points

2025-04-22T07:14:56.3466667+00:00

Thanks the follow-up. Well, it looks like Microsoft continues to have good reason to identify the setting to use UTF-8 as the active system code page as Beta.

Answer 1

Junjie Zhu - MSFT 21,491 Microsoft External Staff

Hello @David H ,

Welcome to Microsoft Q&A!

I was able to reproduce the same behavior and using SetWindowSubclass fixed the issue.

For your scenario, we recommend that you submit this behavior in Feedback Hub. You could find the Feedback Hub in the Start Menu. Please select Developer Platform->API Feedback as the category when you submit your request. The related team will check the request.

If this unexpected behavior has a serious business impact, I suggest that you might need to open a support ticket for this. Please contact our paid support at MS Support. You will get 1:1 support on that. Select Developer Tools -> Windows SDK -> Windows SDK for Windows 10 ->Desktop app UI development ->Windows management (User32) API and Windows messages in the support page and you could contact the team. Please kindly note that your support ticket will be free if it is Microsoft's issue.

Thank you.

David H 0 Reputation points

2025-04-08T06:28:29.8566667+00:00

Thanks. I have also submitted this through the Feedback Hub but I did not choose the categories you recommend. I did, however, provide a link to this page. Not sure if that will help you find it easier. If not, I can submit it again.
Junjie Zhu - MSFT 21,491 Reputation points Microsoft External Staff

2025-04-08T09:37:23.83+00:00

You can share the feedback link.
David H 0 Reputation points

2025-04-10T00:51:06.2366667+00:00

I submitted the feedback anonymously, I did not get a link to it.

Share via

ListView in-place edit box not showing correct Unicode character when typed

1 answer

Your answer