• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 249
  • Last Modified:

Work-around for 4500 word textarea limit

I'm bumping into a 4,500 word/29,395 character limit in my java textarea.  Is there a work-around that would allow me to put more stuff in my java text-areas .. ie. a web-page of material totaling 60,000 + characters?

Thanks so much!
  • 2
  • 2
1 Solution
Back in the days of CPM (I know, ancient history :-) ) Wordstar came up with a Word proccesos that could run on 8K give you a (for then) amazing 40K work space. What was even more amazing, was that you could process a file that was over 360K long! (Well, that was a lot back then).

The way that WS did it should also work well for you.

As long as the text fits in memry, Create 2 Strings, One will contain the total text and the other one will contain a window into the text.

Maintain an int pointer that will allow you to call substring, to extract text from the main text string and store it in the window text (by window, I mean a window int the large text buffer, not an actual window).

Display the contents of the String window on to your textArea. (If you are going to do heavy edditing on the text, set up the window string to contain arround 2/3 of the available space).

Subclass the scroll bars and the appendText()/insertText() methods so that you know when you have reaches the top/bootom of the string window and can store/read another section of the main text. And count the number of characters appended/inserted. When you are close to the textArea limit, append/insert the changed text into the main text buffer.

Its a lot of work but not particularly difficult.

removing text can be handled by obtaining the length() of the window String at the time you load and store a text window. If the values are diferent, or a flag is set by the append/insert methods, you know you will have to replace the section of the main text buffer that was mapped on the text window with the text contained in the window .

Hope this answers your question.
askrinskyAuthor Commented:
(Edited by Computer101) that looks like a pain.  But thanks for your keen insights.

Why the limit anyway?  What's your read?

Thank you so much,

askrinskyAuthor Commented:
Does the limit apply in JavaScript too?  I think it does unfortunately... what to do then?
>Why the limit anyway? What's your read?

The limits existance is not Java's fault, but the undering plattforms. (Windows to be precise).

Remember that allmost all of the AWT is handled by peer classes, which translates to native calls. When MS designed Windows (back in the days of Win 2.0) they figured that an upper limit of 32K was more then enough for an edit window. In those days memory models only allowed you 64K total for the data section of your program.

Of course, MS never figured on the future growth of hardware (no news here). Unfortunatley, MS's solution to the problem was the Rich Text edit control, which is not portable to other platforms.

Sun was therfore forced to choose between not porting for Windows or limmiting textField size for all plattforms. The market sort of forced a desition there.

>Does the limit apply in JavaScript too? I think it does unfortunately... what to do then?

Yes it does.

You can use Live Connect and let the applet handle the buffering for you

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now