I have an edit control that I use in a read-only state for displaying console output to the user. However, the default buffer indicates 30000 max bytes, and I've tried hard to increase it so within the control it can show a much larger range of text when the user tries to scroll through it. I followed this article from msdn to the tee, and it does not work at all. When I retrieve the size of the buffer, it always indicates 30k, no matter how much allocating I do when I trap an EN_ERRSPACE or an EN_MAXTEXT.

quote: Allocating a Text Buffer When the system creates an edit control, it automatically creates a text buffer, sets its initial size, and increases the size as necessary. The size can be up to a predefined limit of approximately 32 KB for single-line edit controls. Because this limit can change, it is called a soft limit. An application can set a hard limit to the buffer size by sending an EM_SETLIMITTEXT message to the edit control. If the buffer exceeds either limit, the system sends the application an EN_ERRSPACE message. An application can retrieve the current text limit by sending an EM_GETLIMITTEXT message. The system typically creates an edit control buffer in a dialog box, using memory outside the application's data segment. An application can suppress this default allocation behavior and create the buffer from its local heap by using the DS_LOCALEDIT style when creating the edit control. An application that uses the DS_LOCALEDIT style is responsible for all buffer allocations. To make the initial allocation, an application can call the LocalAlloc function and pass the returned buffer handle to the edit control by sending it an EM_SETHANDLE message. To make subsequent allocations (in response to an EN_ERRSPACE message, for example), an application should save the current buffer content (if necessary) and obtain a new buffer as follows. To save the current buffer and obtain a new one Retrieve the handle of the memory currently allocated for the text in a multiline edit control by sending the control an EM_GETHANDLE message. Free the buffer by calling the LocalFree function. Obtain a new buffer (and buffer handle) by calling LocalAlloc. Give the buffer handle to the system by sending the control an EM_SETHANDLE message. The EM_SETHANDLE and EM_GETHANDLE messages apply only to multiline edit controls. An application that uses the default allocation behavior (that is, does not use the DS_LOCALEDIT style) must not send EM_SETHANDLE and EM_GETHANDLE messages to the edit control. Sending an EM_SETHANDLE message has several side effects: it clears the undo flag (making the EM_CANUNDO message return zero), it clears the modify flag (making the EM_GETMODIFY message return zero), and it redraws the edit control window.

I know I'm either following the wrong tip or not understanding something. All in all, I could just as easily create my own child scroll window and it would display as much as I can allocate a vector of strings or chars to hold. But I do like the ability for the user to copy and paste text from that window, and I'm not sure if that behavior can be exploited without using the edit control? Ideas please? [edited by - nervo on April 15, 2004 1:45:39 AM]

Rich Edit ought to allow you more characters if you can''t get it to use more characters.

Does anyone have any other suggestion? I really am stumped on this one.

It appears that your code is replacing the buffer there. With mine I want to continue to append to it for much larger than 32k

Doesn''t work for me, I just don''t know why. But aside from that, I should be able to allocate buffer space greater than 32k somehow. Google hasn''t been help to me. I''m also quite confused on the notion that there is a difference in the buffer of the user being able to enter text or text being written to the control. The user is never able to enter text here, just what I output. This is tearing me up. Some of the msdn articles are grossly out of date too.