Automatic ANSI<>Unicode message translation

[Troy Rollo]

On Tue, 26 Jul 2005 17:31, Dmitry Timoshkov wrote:
> > What about the character codes which can't be converted?
>
> A->W conversion doesn't have that problem

That is not necessarily true. A DBCS lead byte without a valid trail byte will 
result in failure in an A->W conversion.

In fact translating from the 'A' version of WM_CHAR to the 'W' version is 
likely to be wrong. Compare WM_IME_CHAR to WM_CHAR:

WM_IME_CHAR has wParam set to ((lead_byte << 8) | (trail_byte)) for DBCS 
characters. WM_CHAR receives DBCS characters as two WM_CHAR messages.

This means that if you SendMessageA a DBCS lead byte, any conversion to a W 
window procedure would need to involve caching that byte and returning 
immediately, then performing the translation.

On the other hand SendMessageA of any character to an A window procedure 
(regardless of any DBCS rules that might apply) ought to pass the character 
through immediately.

This means that ideally, if the window is not a unicode window, then there 
should be no A->W->A translation.

On the other hand perhaps Windows is doing some kind of caching, but if it is 
then it's doing something very strange. When I tested this I noticed an 
anomoly on Win2K - if I called PostMessageA(hWnd, WM_CHAR...) followed by 
PostMessageW(hWnd, WM_CHAR...), the character posted with PostMessageW 
arrived at the A window procedure first. I didn't bother to investigate why 
this happened.