Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

[$$$]How can we make textarea editing faster?

Status
Not open for further replies.

faraway

Programmer
Jun 26, 2003
11
CA
Hi,
We have a textarea which has huge data inside, when we try to edit something within it, the speed is very slow, is there any way to make the editing speed faster?
 
Hi faraway,

How much text are we talking about? In a single textarea.


/Jakob
 
There are about 30 - 50 pages of content inside that textarea.
 
[surprise]

What are you doing w/ 30-50 pages in one textarea?

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook (No, I'm not Rick)

fart.gif
 
Hi mwolf00,

If you can help, I appreciate that. If you just want to kill your time, please go to other places and make fun.
 
faraway - if you spend some time reading threads here, you will see that I am generally fairly helpful. As it stands, I cannot picture a web based application that has a text area which needs to hold 30-50 pages. To that point, I'm not sure what you're doing and why. Answering those questions help me help you. Thanks for the dose of attitude.

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook (No, I'm not Rick)

fart.gif
 
I tried looking at but they don't mention any restrictions. Maybe it's a browser issue instead!?

Is there no logic way to split the document into sections?

You probably shouldn't place all sections on one page though §;O)

Regards


Jakob
 
Hi mwolf00,

Sorry about that.

Actually we use <div contenteditable... and textarea to work as editor, sometime the content is very large and the editing speed is very slow. But in Word, even content is huge, it still can be edited very fast. So we just think whether we can change some attribute of div or textarea to make it can be edited much faster.

Thanks,
 
>> So we just think whether we can change some attribute of div or textarea to make it can be edited much faster

Unfortunately this is governed only by the processing power and available RAM on the machine doing the editing. I've had similar problems with clients who complain that my web applications run slowly on their PII clunkers.

Never be afraid to share your dreams with the world.
There's nothing the world loves more than the taste of really sweet dreams.
 
your textarea / div tries to hold all the content in memory at once. Blame your browser for avoiding loads as you scroll a textarea :)

Word on the other hand probably just puts in memory the current and page and the 2 adjacent ones. It can handle 1000 page docs this way.

There probably is a way to split it up logically. How about paging? So if there are more than say 10k chars in the div/textarea you load the current 10k and offer next-page prev-page links to the rest of the content.

Posting code? Wrap it with code tags: [ignore]
Code:
[/ignore][code]CodeHere
[ignore][/code][/ignore].
 
Yep, I agree that you're talking about seeing effect from a combination of individual processors and simple smackdown on the textarea input widgit. One of my applications is a JavaScript calculator and on occasion we shove many thousands of characters in those poor widdle textareas. They handle it, but with nowhere near the facility of, say, a compiled executable with a rich-edit component.

So, comparisons against Word aren't really fair.

I've been bouncing against a similar issue obliquely while working on a pure JavaScript word processor.

I guess the short answer to your question is:
[ol][li]Make sure your user is aware that operating speed is heavily dependent upon their own client-side configuration.[/li][li]Make darn sure that your algorithms are as speedy as they can possibly be.[/li][/ol]

Cheers,


[monkey] Edward [monkey]

&quot;Cut a hole in the door. Hang a flap. Criminy, why didn't I think of this earlier?!&quot; -- inventor of the cat door
 
HTML forms aren't really designed to manipulate large documents. If they do so slowly and under protest you should take that as a hint!

Are you sure that a textarea is the only way to do what you want to do? Could you not have your users prepare the document in Word (or whatever) and upload it using a <input type=&quot;file&quot;> control? Alternatively, maybe you can find a Java applet that handles large documents better.

-- Chris Hunt
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top