Is GetItemText limited to 256 bytes for CString ?

[Wormhole5230]

There are two types of function to extract a text in the list item in CListCtrl. One is CString GetItemText( int nItem, int nSubItem ), and the other is int GetItemText( int nItem, int nSubItem, LPTSTR lpszText, int nLen ). In case of using the first function, it looks like it can only extract 256 bytes, even the text is over 256 bytes. It is OK for second function. I don't know why the length is limited for CString. Any idea to resolve this problem with CString? Should I use second function? Thanks.

[Lost User]

Perhaps the first function uses the second with a length value of 256 ? Probably easiest to write your own function which is equivalent to the first but with a larger length limit. Elaine :rose: The tigress is here :-D

[Wormhole5230]

OK, that's no problem but what happened to CString, is it bug or not? Thanks.

[Lost User]

Its not a bug in CString, its the function that returns CString. They have to call the original function and in the course of that add the length parameter. And thinking that 256 chars would have been enough.... If you look at the library code there will be a GetBuffer(256) statement with the length also set to 256. Make sure these match in your code or you could get an overflow. Elaine :rose: The tigress is here :-D

[David Crow]

What are you using to verify the length of the CString object? Have you stepped into CListCtrl::GetItemText() to watch how it is behaving?

[Wormhole5230]

I just used GetLength() to check the length of the returned CString object. The return value is 256. The length of the text in the CListCtrl is surely over 256 bytes. The second function can extract whole text when the last parameter nLen is large enought to hold whole text. Thanks.

[David Crow]

Ok, but did you step through the MFC code?

[Wormhole5230]

With your advice, I looked at the MFC code. The function was defined as follows. CString CListCtrl::GetItemText(int nItem, int nSubItem) const { ASSERT(::IsWindow(m_hWnd)); LVITEM lvi; memset(&lvi, 0, sizeof(LVITEM)); lvi.iSubItem = nSubItem; CString str; int nLen = 128; int nRes; do { nLen *= 2; lvi.cchTextMax = nLen; lvi.pszText = str.GetBufferSetLength(nLen); nRes = (int)::SendMessage(m_hWnd, LVM_GETITEMTEXT, (WPARAM)nItem, (LPARAM)&lvi); } while (nRes == nLen-1); str.ReleaseBuffer(); return str; } At first look at, it looks like to extract whole text using do-while statement. But in my code, nRes is 256, so do-while is applied only one time.

[David Crow]

I used the following code snippet and both TRACE() calls output 300: CString str; int len; str = "12345678901234567890123456789012345678901234567890"; str += "12345678901234567890123456789012345678901234567890"; str += "12345678901234567890123456789012345678901234567890"; str += "12345678901234567890123456789012345678901234567890"; str += "12345678901234567890123456789012345678901234567890"; str += "12345678901234567890123456789012345678901234567890"; len = str.GetLength(); TRACE("len = %d\n", len); ctrlList.InsertItem(0, str); str.Empty(); str = ctrlList.GetItemText(0, 0); len = str.GetLength(); TRACE("len = %d\n", len);

[Wormhole5230]

You are right. I found it worked well in alphanumeric text. I'm a Korean. When the string is Korean, it fails. Thanks.

[David Crow]

Makes me wonder if you aren't having a Unicode problem.

[Wormhole5230]

OK, it looks like it definitely related to data-type mapping. I will check it later because of the lack of time. Thank you for your consideration. :)