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.