Thanks for letting us know.
Post by Leslie MilburnPost by Leslie MilburnHi all,
Standard ANSI C Win32 application - no Unicode anywhere.
I want to retrieve the first 7 bytes of the current value of a
Combobox field on a window (all owned).
All values in the Combo Dropdown list are approx 20 bytes
in length.
So the code essentially is
TCHAR Buffer[8];
rc = GetWindowText(hWndCombo, Buffer, sizeof(Buffer));
rc = 8 (although it should be 7 according to the documentation as it
should not include the NULL character).
Under Windows XP SP2
rc = 16 and more importantly it is over-running the buffer.
I have tried calling GetWindowTextA() and I have also tried
SendMessage(..., WM_GETTEXT...) but under Windows XP it is ignoring the
buffer size parameter altogether.
I have confirmed that sizeof(Buffer) is correct, and I have even confirmed
sizeof(TCHAR) is 1 byte.
Can anyone reproduce this problem as it is frustrating the hell out of me.
Leslie.
Hi again,
Ok, heres an update on the problem and its a classic, you know you are alive
when you hit this sort of stuff.
I will write it out in full in case anyone else comes across the problem in
months/years to come.
Firstly the return code from GetWindowText() under Windows XP is *correct*,
it was *always* correct - because the Combobox is actually being seen by
Windows as a Unicode Window. I have confirmed it by calling
IsWindowUnicode().
So, passing 7 to the call was actually asking for 7 TCHARS which are double
byte characters and hence the return value of 14 is correct, its the number
of *BYTES* copied (not characters as documented) - and so hence the buffer
overflow.
How could I be so stupid ?? Well as you will see, I was not. I decided to
check the Parent Window Handle and all Child Controls with the
IsWindowUnicode() function. Guess what, all of them *except* the Combobox in
question are seen as ASCII windows. What the #$%& !!!!
Never before have I seen such a thing happen. So I have spent the last 24 or
so hours trawling through 1000's of lines of preprocessor output trying to
find any function calls with a W on the end, like CreateWindowExW() - but
NO, there are no calls at all which are not what they should be - all using
the A functions where applicable.
Anyway after deleting all unneccessary code I stil had the problem. Ok, so I
created a brand new test application and didn't get the problem. So was it a
memory stomp ? Thankfully not, because then I started to think what was
different about the code. An then it hit me .......
So what is different about this Control ? Ok, are you ready......the control
has a tooltip. When I disable the tooltip on the Combobox, IsWindowUnicode()
indicates the control is ASCII. When I enable the tooltip, it is seen by
Windows as Unicode. I might point out that my tests show that this also
occurs for Edit fields as well.
Here is the code that creates the Tooltip, in the hope that someone can see
anything wrong with it. Its years old and I had pretty much forgotten about
it.
HWND vwCreateToolTip(HWND hWnd,
LPSTR lpText)
{
HWND hWndToolTip;
TOOLINFO ti;
/* Create the Window. */
if ((hWndToolTip = CreateWindowEx(0,
TOOLTIPS_CLASS,
NULL,
TTS_ALWAYSTIP,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
CW_USEDEFAULT,
hWnd,
NULL,
hInstance,
NULL)) == NULL)
return NULL;
/* Ensure that the Tooltip is Topmost. */
SetWindowPos(hWndToolTip,
HWND_TOPMOST,
0, 0, 0, 0,
SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE);
ZeroMemory(&ti, sizeof(ti));
/* Define the Tooltip Attributes. */
ti.cbSize = TTTOOLINFO_V1_SIZE;
ti.uFlags = TTF_SUBCLASS | TTF_IDISHWND;
ti.hinst = NULL;
ti.lpszText = lpText;
ti.uId = (UINT)hWnd;
ti.hwnd = hWnd;
/* Set up the Tooltip Attributes. */
SendMessage(hWndToolTip, TTM_ADDTOOL, 0, (LPARAM)&ti);
return hWndToolTip;
}
So in the above code hWnd is actually hWndCombo. Anyway, once the call has
been made hWndCombo is "upgraded" to become a Unicode Window. Destroying the
Tooltip does not cause the Combo to revert to being an ASCII window though.
Can anyone confirm this finding.
Thanks
Leslie.
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
Robert E. Zaret, eMVP
PenFact, Inc.