This is a migrated thread and some comments may be shown as answers.

Disabling Undo

1 Answer 146 Views
This is a migrated thread and some comments may be shown as answers.
Top achievements
Rank 1
Geoffrey asked on 06 Aug 2010, 05:31 PM
Our clients work with large text fields (greather than 150K) and occasionally have trouble saving them in RadEditor. Previous posts in this forum have mentioned that the Q2 2010 release's new capability to disable RadEditor's Undo/Redo functionality will help when working with large text fields. Here are my questions:

  1. How do you actually disable the RadEditor's Undo in the Q2 2010 release? Do you simply remove the Undo/Redo tools on the menu, or is there some other way?
  2. Once Undo is disabled, what is the maximum field size recommended with RadEditor? Is it now greater than the 100K you have recommended in the past?

Geoff LeBlond
Silverchair Science & Communications

1 Answer, 1 is accepted

Sort by
Telerik team
answered on 09 Aug 2010, 05:13 PM
Hi Geoff,

Indeed, to disable the Undo / Redo feature just remove the Undo and Redo buttons from the toolbar by following the instructions in this KB article: Removing Toolbar Buttons. If you use a ToolsFile.xml file, delete the respective Undo and Redo tool tags. This will allow you to edit larger documents without experience the reported in the past problems.

The information below could be helpful for your scenario as well:

There are five main reasons responsible for the slow editor performance when editing large XHTML/HTML files:

Reason 1: The undo/redo mechanism and other maintenance code that ensures the smooth user experience - it gets increasingly cumbersome and time consuming for the browser to execute it if huge content is in the editor.
Reason 2: The fact that most of the editor functionality is implemented in JavaScript, thus resulting in 10 times slower performance compared to native compiled code.
Reason 3: test the performance only when <compilation debug="false" in your web.config. When it is true, the MS AJAX debugging code kicks in and causes a severe performance hit on the client-side.
Reason 4: Remove the RadEditor modules, e.g.

<telerik:radeditor runat="server" ID="RadEditor1">
        <telerik:EditorModule Visible="false" />


Reason 5 (valid when switching between the view modes or submitting the content): In difference with the TextBox control which does not process the content when submitting it to the server, the RadEditor runs content filters which validate the non well formatted content and make it XHTML compliant. Right now the editor runs more than 11 content filters. These filters run regular expressions which parse and validate the large content, which slow down the content submission to the server. You can disable the filters by setting ContentFilters property to None, e.g.

<telerik:RadEditor ID="RadEditor1" ContentFilters="None" runat="server"></telerik:RadEditor> 

The policy behind all RadControls is that they should be cross-browser and should offer similar experience over different browsers and OS-es. At present the editor supports IE under Windows, Mozilla Firefox under all platforms, Opera under all platforms and Safari under Mac. Such cross-browser functionality is possible only with JavaScript - no other option exists.
Being cross-browser is a top priority, and thus at present it rules out changing the editor's technology.

We are constantly working on improving the speed, but the browsers do have their limits, and it is not hard to reach them when editing large content in the editor.

You can find more information in the following KB article: RadEditor loads slowly (high CPU utilization).

Best wishes,
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
Asked by
Top achievements
Rank 1
Answers by
Telerik team
Share this question