andi at rhlx01.fht-esslingen.de
Sun Dec 15 11:49:22 CST 2002
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:
/* 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
More information about the wine-devel