CRichEditCtrl buffer size smaller than advertised

I'm using a CRichEditCtrl object to dislpay text from my document.  The control lives in the view class.  The .LimitText function implies that the default size of the allowable displayed text is UINT_MAX  but experimentation seems to show it is USHRT_MAX (64K).  What am I doing wrong here?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You're not doing anything wrong - if you call LimitText with param 0 then
it says that 0 means parameter is UINT_MAX.

But if you haven't called LimitText then
the default creation value seems to be

answer - call LimitText to set your
upper bound.

sieglejAuthor Commented:
Thanks Mike,
I tried this but it still doesn't seem to take anything larger than USHRT_MAX.  Do we need to use this class in conjuntion with the other classes (view) or is it OK to use stand alone?  If you have no other suggestions, I'll send the code I tried (I'm offsite for the next day or so). Thanks for your help.
sieglejAuthor Commented:
I'm back and here's the code I'm trying:

      m_rich.GetWindowText( scriptBuffer, 0xffff );            
      m_rich.SetModify( FALSE );

This works OK but if I do this (bump size by 1):

   int size = m_rich.GetLimitText();
      m_rich.GetWindowText( scriptBuffer, 0x10000);            
      m_rich.SetModify( FALSE );

It doesn't work.  GetWindowText returns 0 (bytes copied) even though size is returned from GetLimitText() shows as the correct size.  What am I doing wrong here?

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

sieglejAuthor Commented:
Adjusted points to 150
sieglejAuthor Commented:
This answer didn't solve the problem.  Please see my last comment.  What am I missing here?
From the help on the WM_GETTEXT message
which is at the base of what you are trying to do...

Rich Edit: If the text to be copied exceeds 64K, use either the EM_STREAMOUT or EM_GETSELTEXT message.

It took a while to find in MSDN but it
is there.  Question is - why is it not
further up in the help as well.

Hope this helps you solve your problem.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sieglejAuthor Commented:
Does this mean I have to setup a callback function, etc., etc.. to handle this buffer size?   I'm not familiar with interjecting a different message for the GetWindowText function.  Is this what you mean here?
EM_GETSELTEXT doesn't mean that.  But, unfortunately I cannot find any info
about it's limits.

EM_STREAMOUT/IN is very easy once you get your head round it.  What exactly do
you wish to do with your buffer?

Here is an example of streaming in...

            HANDLE hFile=CreateFile(dlg.m_ofn.lpstrFile,GENERIC_READ,0,0,OPEN_EXISTING,0,0);
                EDITSTREAM EditStream;


callback function...

DWORD CALLBACK EditStreamCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
    HANDLE hFile=(HANDLE)dwCookie;
    if(ReadFile(hFile,pbBuff,cb,(unsigned long *)pcb,0)==0)
        return 1;

    return 0;

you could easily adapt this to streaming out to a file, and with a bit more work you could stream out to a buffer.

hope this helps,
sieglejAuthor Commented:
Ok, your answer fits why GetWindowText doesn't work beyond 64k (use the call back function).  I'll put in an accept.  Can you hang in with me for a bit and explain a bit about the callback.  I just want to grab the data from the control and stuff it in a buffer.  Here's the code:

void      CScriptView::GetWindowText( char* scriptBuffer, int buffSize )
//      m_rich.GetWindowText( scriptBuffer, 0x20000 );      // the size should be the max script buffer size (128K)
//      m_rich.SetModify( FALSE );                        // not modified

      EDITSTREAM      strm;

      strm.dwCookie    = (DWORD)scriptBuffer;            // send the script buffer in the cookie
      strm.dwError     = 0;                        //
      strm.pfnCallback = GetWindText;                  // use call back function to get the CRichEditCtrl data

      m_rich.StreamOut( SF_TEXT, strm );                  // want just the text
      m_rich.SetModify( FALSE );                        // not modified

DWORD CALLBACK      CScriptView::GetWindText( DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG FAR *pcb )
      char      *bp;

      bp = (char *)dwCookie;            // the cookie is the script buffer

      strcpy( bp, (char *)pbBuff );      // copy in the contents of the CRichEditCtrl
      *(bp + cb) = '\0';                  // cut it off at the end

      return ( *pcb = cb );            // return the amount we got

I guess I don't understand what the pbBuff and cb really are because if in my edit control, if I have 12345 and then go back and insert a 0 at the begining, pbBuff points to 0 (that's good) but cb = 1.  What about the rest of the buffer.  I figured the control would just keep track of the changes and give you a pointer and size that matched what was in your control (012345) (not what changed - the 0 at the begining).  Can you hang in with me for a bit more to get this call back figured out?  THANKS!
The control makes multiple calls
to the callback function - are you sure
you are not seeing the later ones.

What i mean is - is the control sending
the 1 byte buffer and then sending lots
of bigger buffers in the subsequent callbacks.

If it is then you need to maintain
an index into your buffer so that
you can copy each chunk in correctly.



also, what is StreamOut returning?

sieglejAuthor Commented:
Hi mike,
Don't know if you are still connected to this question but thanks for your final comments.  Yes indeedy, even though there are only a few bytes in the buffer, multiple calls are required along with bumping the pointer along.  Not sure why they do this, other than they are probably keeping track of buffer contents, keystroke history, etc. and need to piece things together to return them.  Thanks for your help - sorry it took a while to get back to this (life in manufacturing....)!
Hi Jeff,

No problem with the delay.

Glad to hear you fixed it.  I have noticed the same effect in my code

Fortunately for me I stream
to a file mostly, so I had to write for that possibility from the start.

I only noticed it later stepping through code.

Thanks for the feedback - wish our
customers took the time to do the same.


It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.