Self-registered edit control class crashes because of wrong GetWindowTextLength return value
-
Hello, long title, short story: a rather old third-party library uses the following code to register its own edit control class:
static const TCHAR BASED_CODE szEdit[] = _T("GXEDIT"); WNDCLASS wcls; // check to see if class already registered if (!::GetClassInfo(hResource, szEdit, &wcls)) { // Use standard "edit" control as a template. VERIFY(::GetClassInfo(NULL, _T("edit"), &wcls)); // set new values wcls.style |= GX_GLOBALCLASS; wcls.hInstance = hResource; wcls.lpszClassName = szEdit; AfxRegisterClass(&wcls);This works fine unless XP themes are enabled. If they are and I use GetWindowText(CString-variable) with this edit control, the CString destructor causes a heap corruption because ::GetWindowTextLength reports less bytes than ::GetWindowText actually receives, and thus CString::GetBufferSetLength allocates not enough memory. Is there a simple solution to change the above code so that this GXEDIT works with XP themes? I already tried rewriting it using WNDCLASSEX instead, but that didn't help. adTHANKSvance, Jens -
Hello, long title, short story: a rather old third-party library uses the following code to register its own edit control class:
static const TCHAR BASED_CODE szEdit[] = _T("GXEDIT"); WNDCLASS wcls; // check to see if class already registered if (!::GetClassInfo(hResource, szEdit, &wcls)) { // Use standard "edit" control as a template. VERIFY(::GetClassInfo(NULL, _T("edit"), &wcls)); // set new values wcls.style |= GX_GLOBALCLASS; wcls.hInstance = hResource; wcls.lpszClassName = szEdit; AfxRegisterClass(&wcls);This works fine unless XP themes are enabled. If they are and I use GetWindowText(CString-variable) with this edit control, the CString destructor causes a heap corruption because ::GetWindowTextLength reports less bytes than ::GetWindowText actually receives, and thus CString::GetBufferSetLength allocates not enough memory. Is there a simple solution to change the above code so that this GXEDIT works with XP themes? I already tried rewriting it using WNDCLASSEX instead, but that didn't help. adTHANKSvance, JensAre you sure there is such a bug affecting
GetWindowTextLength? I cannot find related info.If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke -
Hello, long title, short story: a rather old third-party library uses the following code to register its own edit control class:
static const TCHAR BASED_CODE szEdit[] = _T("GXEDIT"); WNDCLASS wcls; // check to see if class already registered if (!::GetClassInfo(hResource, szEdit, &wcls)) { // Use standard "edit" control as a template. VERIFY(::GetClassInfo(NULL, _T("edit"), &wcls)); // set new values wcls.style |= GX_GLOBALCLASS; wcls.hInstance = hResource; wcls.lpszClassName = szEdit; AfxRegisterClass(&wcls);This works fine unless XP themes are enabled. If they are and I use GetWindowText(CString-variable) with this edit control, the CString destructor causes a heap corruption because ::GetWindowTextLength reports less bytes than ::GetWindowText actually receives, and thus CString::GetBufferSetLength allocates not enough memory. Is there a simple solution to change the above code so that this GXEDIT works with XP themes? I already tried rewriting it using WNDCLASSEX instead, but that didn't help. adTHANKSvance, JensMaybe its a Unicode/ANSI issue. The third party control may be using Unicode. Windows Unicode (UTF-16) uses 2 bytes to represent each character. Try changing your GetWindowText to GetWindowTextW and see what happens, perhaps you need a CStringW. Best Wishes, -Randor (David Delaune)
-
Are you sure there is such a bug affecting
GetWindowTextLength? I cannot find related info.If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain ClarkePart of this third-party library is a grid control, and the problems occurs when a GXEDIT control is created in-place to edit the contents of a cell. The cell contains a 4-digit number, and the value returned by GetWindowTextLength is 12. But only if I discard this value and reserve 25 bytes or more in CString::GetBufferSetLength, the heap doesn't get corrupted. It's strange, but I think this is only a side effect of some error in the class registration. If I don't use the XP visual styles for this app (no manifest file), everything works fine. Other edit controls that are of the systems standard "edit" class type, work ok with or without styles enabled... Regards, Jens
-
Maybe its a Unicode/ANSI issue. The third party control may be using Unicode. Windows Unicode (UTF-16) uses 2 bytes to represent each character. Try changing your GetWindowText to GetWindowTextW and see what happens, perhaps you need a CStringW. Best Wishes, -Randor (David Delaune)
The control does not use unicode, I have checked that. As I wrote, the problem only occurs if I enable XP visual styles and themes for the application by including a manifest file in the executables directory. I already tried to write replacements for Get/SetWindowText:
void CGXEditControl::GetWindowText(CString& s) { if (IsThemeActive()) { const int nLen = ::GetWindowTextLengthW(m_hWnd); CStringW sW; ::GetWindowTextW(m_hWnd, sW.GetBufferSetLength(nLen), nLen+1); sW.ReleaseBuffer(); s = sW; } else { //CGXEditControl is derived from CEdit, CGXStatic CEdit::GetWindowText(s); } } void CGXEditControl::SetWindowText(const CString& s) { if (IsThemeActive()) { CStringW sW(s); ::SetWindowTextW(GetSafeHwnd(), sW); } else { CEdit::SetWindowText(s); } }This prevents the heap corruption, but then the edit control contains a lot of unreadable stuff like arabic letters :omg: even though the debugger shows that sW seems to contain a correct string like "1120". The problem seems to be the registration process of the class GXEDIT. In CGXEditControl::CreateControl, if I replace the class name "GXEDIT" with the standard "edit" class in the call to CEdit::Create, everything works! But I don't know what side effects this will have for the rest of the library :confused:, so I want to avoid this workaround if possible. BTW, this library is a very antique version of Stingray's Objective Grid, dated 1997 :-O . Regards, Jens
