(Multiline) Edit Control Limit

Reading one of msdn's technical articles and having experimented with the edit control I found this:

Quote:

---

Edit controls were designed to enter, display, and edit small amounts of text. They were not meant to be the basis for large-scale text editors. Edit controls in Microsoft® Windows™ have the following limits:
Multiple-line edit controls are limited to a maximum of 64K (65,535 bytes) of text. Whether a multiple-line edit control is actually able to approach this limit is based on how the edit control uses memory. - http://msdn.microsoft.com/en-us/library/ms997530.aspx

---

This raises the question of how are "large-scale text editors" created then, notepad can edit massive amounts of text over the limit of 64k? Using Spy++ the class of the input control on notepad is an "edit", I don't know if they have edited this or it is actually an edit control. There are alot of text editors out there and the edit control stuffs up the line numbering when the multiline edit control has >= 10 lines (I don't know if this is just my app). Also from the quote:

Quote:

---

Whether a multiple-line edit control is actually able to approach this limit is based on how the edit control uses memory.

---

Note the word "approach" this does not include going beyond like notepad (and probably other apps do). If anyone has heard of UEStudio (a commercial IDE), the main input control has a class called "EditControl" this can display rulers within it, the number of lines within the file and lots of other stuff including multi-colours.

I suspect the fact that the article you link to refers to an older version of Edit Control than that used today - for example, the Win 3.x version of Notepad was only capable of editing a 64KB file. I'm not sure if Win95 or WinNT 4.0 (or maybe even later versions) was the first one to extend the size of notepad's capability.

--
Mats

I was always under the impression that only a rich-edit control could exceed 64kbs and saving a larger file would by default be opened up by wordpad.

That was the 9X era. Windows XP notepad can open large files, as well.

Yeah it is an old version of the edit control, I didn't notice the date: January 31, 1992; Updated October 16, 1992. I saw it and found it explained why the edit control in my app did not work very well with large files and thought that if the edit control had more than 64k of text, text could be deleted by not added. Guess I'll look at the date from now on as not much seems to have changed in the way of edit controls since the Ms Windows versions 3.0 and 3.1 SDK.

Quote:

---

This raises the question of how are "large-scale text editors" created

---

Helpful links:

Memory management for large file editors part 1

Memory management for large file editors part 2

Essentially, you're just using an edit control to "view" one page of an extremely large document at a time.

New edit controls still have this limit and rightly so. For large amounts of data you must use some type of paging mechanism. Increasing the max limit of the edit control wouldn't work because it could never increase to exactly what you need since everyone's use of the control is different. Thus they set the limit at 64kb and let you the programmer figure out how to page data in and out of it.

Thanks BobS0327, thats exactly what I was looking for, and some other great articles as well :). I am greatly appreciative of the great Windows prog. links. ha, create an app that is faster than notepad, nice :).

>> New edit controls still have this limit...
Not that I can tell. The edit control text buffer handling documentation suggests that it uses LocalAlloc/LocalFree for it's buffer: http://msdn.microsoft.com/en-us/libr...px#text_buffer Although that may be the case only after an EM_GETHANDLE message...

In any case, I just set a 100K of text to a multi-line edit control with a test app - worked ok.

gg

Perhaps my experience then has been limited to MFC which might use an older version of the edit control that has the 64kb limit. Regardless of the limit at some point a paging scheme will have to be devised in order to open huge files.

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 kilobyte (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 (see "Dialog Box Template Styles" in About Dialog Boxes) 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.

---

Appears that only single line edit controls have the soft limit. Multi-line's limit, from the docs, appear to be set by the user of the control. Interesting.

Thanks for the link and the information.