GetWindowTextLengthA()/WM_GETTEXTLENGTH issue

[Andreas Mohr]

Hi all,

Steuertipps PC 2003 (yeah, right, it's that time of the year again ;)
has corrupted button text - drawing beyond the last actual string character.

This is because the supplied OWL (Borland, I believe ?) DLL calls DrawTextA
with twice the amount of string length (yeah, must be a Unicode issue,
of course... :), thus forcing DrawTextA into drawing way too much.
(side note: OWL seems to implement its own custom buttons)

This doubled value comes from GetWindowTextLengthA() (0x14 bytes instead
of 0x0e bytes), which thus comes from WM_GETTEXTLENGTH.

WINPROC_UnmapMsg32ATo32W does for a WM_GETTEXTLENGTH unmapping:
    case WM_GETTEXTLENGTH:
    case CB_GETLBTEXTLEN:
    case LB_GETTEXTLEN:
        /* there may be one DBCS char for each Unicode char */
        return result * 2;

The button text in question is:
L"&Schlie\00dfen"  (aka "&Schliessen")
(so it's a Unicode string with 0x0e units)

MSDN says that both WM_GETTEXTLENGTH and GetWindowTextLength return inexact
amounts of string lengths for certain Unicode/DBCS combos (and always
at least as much as the minimum storage it requires).
However, I guess that we really *shouldn't* double the string length in this
case (I guess we better avoid that corruption ;).

Hmm, any idea how the unmapping can be improved ?
To me it seems that the generic unmapping in WINPROC_UnmapMsg32ATo32W
is exactly the place where s^Hcrap happens.
(there seems to be a pretty direct connection between GetWindowTextLengthA
and DrawTextA)

Andreas Mohr