Setting History Depth or IsEnabled is clearing Redo stack

[Bob]

 

I am working with the RadRichTextBox Document History, and I noticed that whenever I change the Depth of the Undo stack, or change IsEnabled, the Redo stack is cleared, but the Undo stack is preserved.  Is there any way to preserve the Redo stack during these changes?

For example:

myRadRichTextBox.Document.History.Depth = newDepthLimit;

and

myRadRichTextBox.Document.History.IsEnabled = false;

 

will both clear the Redo stack.  I am trying to prevent a callback command that manipulates a bookmark from adding an element to the history, but if I use either of these methods, I lose the Redo stack.

 

Thanks,

Bob

 

[Tanya]

Hello Bob,

Changing the IsEnabled and Depth properties of the document history indeed clears the redo stack by design. Executing undo or redo over a document with a changed structure can result in an invalid document and might lead to different unexpected behaviors. Clearing the history stack guarantees that this won't happen. 

I am not sure what exactly you need to prevent from being inserted into the History stack, but you can do some modifications on the document content by directly changing the model - modifying the properties of the document elements, or inserting in their Children collections, for example. Would that be an option for your scenario?

Regards,
Tanya
Progress Telerik

[Bob]

Hello Tanya,

We use the RadRichTextBox with custom commands that insert images, videos, and math expressions (MathML).  When we do this, the inserted inline image object is then wrapped in a Bookmark so that it can be properly identified and indexed.

Since the author may use the delete key or backspace to remove the inline image, we also re-index these objects on a content changed event.  It is during this content changed event that I was trying to prevent updates to the undo/redo stack, and where I discovered that the redo stack was cleared.

However, I have found a workaround where I can simply change the bookmark name in the content changed handler, and this does not add any history to the undo stack. 

Here is the basic code I am using now, and this works with undo/redo successfully.

int imageInlineCount = 0;

foreach (ImageInline image in editor.Document.EnumerateChildrenOfType<ImageInline>())
{
    imageInlineCount++;
    string bookmarkName = $"bookmarkID with index {imageInlineCount}";

    var imageBookmark = image.PreviousSibling;

    ((BookmarkRangeStart)imageBookmark).Name = bookmarkName;
}

 

Thanks,

Bob

[Bob]

I have an additional question related to undo/redo history.  Is there any way to save/restore the history along with a document?  For example, if I save the XAML to the database, and then refresh the editor with the same content, can I also load the undo/redo stack with it?

[Tanya]

Hi Bob,

Indeed, changing the bookmark name directly through the model won't add a record in the History for that action. Another option that you might find useful is to group several actions into a single history record. For example, when an image is deleted, you can cancel the default command and instead create an undo group that deletes the image and the bookmark associated with it. An example of how to group several actions into a single record is shown in the second snippet of How to use RadDocumentEditor.

When it comes to preserving the history along with the document, such a concept is not available in any of the rich text document formats. I have discussed with the development team the possibility of adding such functionality when exporting to XAML. However, implementing that would require a lot of resources, and having all that information inside the document will extremely enlarge its size. The history needs to preserve the specific state of the document and elements inside along with a bunch of information about the command being executed and the order of different commands. All that serialized in XAML will result in a much bigger document. That is why we are not considering adding functionality that can preserve the document history on import/export.

I hope the provided information is useful.

Regards,
Tanya
Progress Telerik

[Bob]

Thank you Tanya, I have this working nicely now.  I appreciate that the effort to persist the history would be challenging.  We are currently persisting our documents by capturing an HTML snapshot of the document at points in time, and they are stored in our database.  The users can restore to these points in time in bulk, but they cannot undo single actions once they have saved the document to a common store.  If it was easy to persist the history, we could add that feature, but it looks like we will continue to use our snapshots.   -- Bob

[Tanya]

Hello Bob,

I am glad to hear that you managed to find an option that suits your needs and would like to thank you for your understanding. Indeed, this functionality would require a lot of effort for its implementation, and due to the inevitable side effects that come with it, I believe it won't be acceptable for a big part of our customers. 

Regards,
Tanya
Progress Telerik