SteveGTR
asked on
::GetWindowText/RichEdit Inconsistencies
I'm using VC++ 6.0/SP4 on Windows NT 2000/SP2. The problem I've discovered is inconsistencies in what ::GetWindowText() returns when it is passed a handle to a RICHEDIT control.
In the example below IDC_EDIT is a RICHEDIT control and there has been over 255 characters entered in the field.
-----
CString str;
int nResult = ::GetWindowText(GetDlgItem (IDC_EDIT) ->m_hWnd, str.GetBuffer(256), 256);
str.ReleaseBuffer();
CString strResult;
strResult.Format("::GetWin dowText() returned: %d Value: \n%s", nResult, (LPCTSTR) str);
AfxMessageBox(strResult);
-----
On my machine (NT2000) ::GetWindowText() returns 0 and str is empty. Calling ::GetLastError() returns 122 (ERROR_INSUFFICIENT_BUFFER ). A true statement, but the documentation says:
-----
int GetWindowText(
HWND hWnd, // handle to window or control
LPTSTR lpString, // text buffer
int nMaxCount // maximum number of characters to copy
);
Parameters
hWnd
[in] Handle to the window or control containing the text.
lpString
[out] Pointer to the buffer that will receive the text.
nMaxCount
[in] Specifies the maximum number of characters to copy to the buffer, including the NULL character. If the text exceeds this limit, it is truncated.
-----
On NT4/SP5 and on Windows 95 the function returns 255 and str is equal to the first 255 characters.
I'd have expected XP to act the same as NT 2000, and it does sort of. It returns 0, but str is set to the 1st 256 of data. This is alarming, because I first discovered this problem in the DDX_Text() processing. The AfxSetWindowText() utility function located in WINUTIL.CPP defines a buffer like so:
TCHAR szOld[256];
Then calls the API like so:
::GetWindowText(hWndCtrl, szOld, _countof(szOld))
I wonder if it returned the NULL also? If so, then the stack is messed up.
Has anyone seen this behavior before?
Thanks,
Steve
In the example below IDC_EDIT is a RICHEDIT control and there has been over 255 characters entered in the field.
-----
CString str;
int nResult = ::GetWindowText(GetDlgItem
str.ReleaseBuffer();
CString strResult;
strResult.Format("::GetWin
AfxMessageBox(strResult);
-----
On my machine (NT2000) ::GetWindowText() returns 0 and str is empty. Calling ::GetLastError() returns 122 (ERROR_INSUFFICIENT_BUFFER
-----
int GetWindowText(
HWND hWnd, // handle to window or control
LPTSTR lpString, // text buffer
int nMaxCount // maximum number of characters to copy
);
Parameters
hWnd
[in] Handle to the window or control containing the text.
lpString
[out] Pointer to the buffer that will receive the text.
nMaxCount
[in] Specifies the maximum number of characters to copy to the buffer, including the NULL character. If the text exceeds this limit, it is truncated.
-----
On NT4/SP5 and on Windows 95 the function returns 255 and str is equal to the first 255 characters.
I'd have expected XP to act the same as NT 2000, and it does sort of. It returns 0, but str is set to the 1st 256 of data. This is alarming, because I first discovered this problem in the DDX_Text() processing. The AfxSetWindowText() utility function located in WINUTIL.CPP defines a buffer like so:
TCHAR szOld[256];
Then calls the API like so:
::GetWindowText(hWndCtrl, szOld, _countof(szOld))
I wonder if it returned the NULL also? If so, then the stack is messed up.
Has anyone seen this behavior before?
Thanks,
Steve
Just a hunch, but I'll bet that this is a security-related issue. Maybe there is a buffer overrun exploit possible if GetWindowText works as advertised.
-- Dan
-- Dan
ASKER
Maybe I didn't make it clear in my long spewing forth of information. I discovered this problem in the DDX_Text() processing. I was looking into a problem where a RICHEDIT control was not being reset to blank when the user requested a new record. The value of the control had been over 255 characters and was being set to 0 characters.
Here is the flow:
m_strMyRichEdit = _T("");
UpdateData(FALSE);
As you know in the DoDataExchange() function there will is the following:
DDX_Text(pDX, IDC_MYRICHEDIT, m_strMyRichEdit);
This function executes the DDX_Text() function in DLGDATA.CPP that calls AfxSetWindowText() in WINUTIL.CPP:
void AFXAPI AfxSetWindowText(HWND hWndCtrl, LPCTSTR lpszNew)
{
int nNewLen = lstrlen(lpszNew);
TCHAR szOld[256];
// fast check to see if text really changes (reduces flash in controls)
if (nNewLen > _countof(szOld) ||
::GetWindowText(hWndCtrl, szOld, _countof(szOld)) != nNewLen ||
lstrcmp(szOld, lpszNew) != 0)
{
// change it
::SetWindowText(hWndCtrl, lpszNew);
}
}
There is the reference to ::GetWindowText(). On NT 2000, 0 is returned and no data is placed in szOld. So the "if" statement resolves to FALSE. The result is the field does not get updated and remains equal to the previous value.
So all this is stock MFC processing.
Thanks for looking at this Dan. I really appreciate it.
Here is the flow:
m_strMyRichEdit = _T("");
UpdateData(FALSE);
As you know in the DoDataExchange() function there will is the following:
DDX_Text(pDX, IDC_MYRICHEDIT, m_strMyRichEdit);
This function executes the DDX_Text() function in DLGDATA.CPP that calls AfxSetWindowText() in WINUTIL.CPP:
void AFXAPI AfxSetWindowText(HWND hWndCtrl, LPCTSTR lpszNew)
{
int nNewLen = lstrlen(lpszNew);
TCHAR szOld[256];
// fast check to see if text really changes (reduces flash in controls)
if (nNewLen > _countof(szOld) ||
::GetWindowText(hWndCtrl, szOld, _countof(szOld)) != nNewLen ||
lstrcmp(szOld, lpszNew) != 0)
{
// change it
::SetWindowText(hWndCtrl, lpszNew);
}
}
There is the reference to ::GetWindowText(). On NT 2000, 0 is returned and no data is placed in szOld. So the "if" statement resolves to FALSE. The result is the field does not get updated and remains equal to the previous value.
So all this is stock MFC processing.
Thanks for looking at this Dan. I really appreciate it.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the verification Dan. I've submitted this as a bug to Microsoft.
In the thousands of Q's I've read here, I've seen dozens claiming the problem is a bug in MFC. This is the first one that I could verify. And this bug exists only because of an unexpected change to a Win32 API function that one would think was chiseled in granite.
The most significant thing is that the same error occurs for a regular old Edit control. It might also exist for other controls, such as ListBoxes and ComboBoxes, and Popup Window titles etc. (though these will rarely be affected because >256 chars there would be unusual...)
If you ever hear back from MS, I'd be interested in what they have to say. I have the latest MFC source code from DevStudio.NET at home. I'll check it to see if this bug was quietly corrected 'inline'
-- Dan
The most significant thing is that the same error occurs for a regular old Edit control. It might also exist for other controls, such as ListBoxes and ComboBoxes, and Popup Window titles etc. (though these will rarely be affected because >256 chars there would be unusual...)
If you ever hear back from MS, I'd be interested in what they have to say. I have the latest MFC source code from DevStudio.NET at home. I'll check it to see if this bug was quietly corrected 'inline'
-- Dan
ASKER
Dan,
I believe that this is a bug in NT2000 and XP handling of RICHEDIT controls. It happens to surface in MFC code. The way XP handles the function really scares me.
Also, this problem does occur when dealing with EDIT controls. The ::GetWindowText() function will return 255 and truncate to the 1st 255 characters for EDIT controls. Having said that, I've only tested that on NT2000. It's Friday and I'm just too lazy to walk to the other end of the office to test it on XP :)
Have a great weekend.
I believe that this is a bug in NT2000 and XP handling of RICHEDIT controls. It happens to surface in MFC code. The way XP handles the function really scares me.
Also, this problem does occur when dealing with EDIT controls. The ::GetWindowText() function will return 255 and truncate to the 1st 255 characters for EDIT controls. Having said that, I've only tested that on NT2000. It's Friday and I'm just too lazy to walk to the other end of the office to test it on XP :)
Have a great weekend.
ASKER
The Also sentence should have a "not" after does. As in, "Also, this problem does not occur when dealing with EDIT controls".
That's what I get for not proofing my messages...
That's what I get for not proofing my messages...
However, this is kinda subtle: It doesn't say "it will be truncated to the specified length" just "it will be truncated." Thus, the documentation is correct, if misleading.
You probably already know the various workarounds, but in case you don't, I'll list a couple. The simplest is:
MFC:
CString str;
GetDlgItem(IDC_EDIT)->GetW
For some reason, you are mixing MFC and Win32 API, so I'll show you the pure Win32 version:
Win32 API:
int nLen= ::GetWindowTextLength( hWndOfEditCtrl );
char pszText= new char[nLen];
::GetWindowText( hWndOfEditCtrl, nLen );
In other words, do what MFC does: Request the length, then provide a buffer that large. You will always get the data.
-- Dan