Re: more brain-dead design: GetCueBanner
"Joseph M. Newcomer" <newcomer@flounder.com> ha scritto nel messaggio
news:0u80n45ir3ijc515kppt56oi3ko2bd1oo8@4ax.com...
It is unfortunate that whoever designed GetCueBanner didn't actually think
about the fact
that people will need to use it. For example, in a rational world,
EM_GETCUEBANNER would
return not TRUE or FALSE, but would return the number of characters put in
the buffer. And
it would handle the fact that if WPARAM, LPARAM were 0,0 it would return
the size of the
banner in characters + 1. This would make sense. But alas, not only is
there no way to
find this out, there isn't even an EM_GETCUEBANNERLENGTH message!!!!!
Joe: there is an overload of CEdit::GetCueBanner, that returns a CString (so
you don't explicitly have to pass the maximum text size buffer, like with
raw EM_GETCUEBANNER message).
So, if you read the aforementioned CEdit::GetCueBanner overload
implementation, you can have an idea on how it does for the output string
length.
I've found in VS2008 that it just calls an helper template function
CWnd::EnlargeBufferGetText<T>:
<code>
AFX_INLINE CString CEdit::GetCueBanner() const
{
ASSERT(::IsWindow(m_hWnd));
LPTSTR lpszText=NULL;
int cchText = 0;
CString strOut("");
BOOL b = CWnd::EnlargeBufferGetText<BOOL>(FALSE, lpszText, cchText,
EM_GETCUEBANNER, (WPARAM&)lpszText, (LPARAM&)cchText, strOut);
if (b)
return strOut;
else
return CString("");
}
</code>
If you anlyze the code of CWnd::EnlargeBufferGetText<T> in afxwin.h, you can
see that it uses a loop, starting from 256 maximum character count up until
INT_MAX, and it doubles the size of the temporary buffer at each loop
iteration, until the returned string is not truncated, and the maximum limit
of INT_MAX is not surpassed.
However, I think that it is a "patch" that MFC developers put to fight this
poor design of this particular Win32 API.
I do agree with you that having a EM_GETCUEBANNERLENGTH would be much much
better (like they wisely gave us WM_GETTTEXTLENGTH).
Giovanni