Replacing content without moving current selection

[Yiannis]

Hello all,

How can I replace contents using RadRichTextBox/RadDocumentEditor without moving the RadDocument.Selection to the range I want to change?

Moving and restoring the selection seems to work will scroll the document to the new selection position, which is undesired.

After going through similar posts, I found that I can insert content at an arbitrary location using the InsertFragment(DocumentFragment, DocumentPosition) method, but no way to replace a whole range (e.g. defined by two DocumentPosition instances) or even delete the contents of an such a range.

[Boby]

Hi Yiannis,

You are right, such API is not exposed for now, and most of the methods (except InsertFragment and InsertPosition) in IDocumentEditor work with Document's current Selection and Position, which causes changes in the vertical offset. 

I will log this as a feature request in our portal:
RichTextBox: Do not change the scroll position, caret position and current selection during editing operations with the API

As a workaround, you can additionally save the offset before the edit operation and restore it afterwards:

double offset = this.radRichTextBox.VerticalOffset;
this.radRichTextBox.ScrollToVerticalOffset(offset);

which is not perfect, but will probably work good enough in most cases.

Regards,
Boby
Progress Telerik

[Yiannis]

Thank you Boby,

Your advice about maintaining the vertical scroll offset seems to be a good workaround. This, along with the restoration of the current selection and caret point after the edit operations complete should be enough for now.

Can you please advise whether there is a public method to "freeze" the viewport so that any flickering because of the scroll offset changes is not visible?

[Boby]

Hello Yiannis,

Can you reproduce the flickering in a simple application? I just tried several small examples and it seems that the document is not scrolled - I guess because the layout updates not often than RadDocument.DocumentContentChangedInterval, which is 30 ms by default. A real example would help in find a solution. You may need to open a support ticket, as attaching files is not allowed in the forums.

Regards,
Boby
Progress Telerik

[Yiannis]

I did not see any flicker when I tried the work-around and the 30ms interval seems to be the explanation. Is it safe to set the interval to something big, effectively freezing the layout, during the content changes, and restoring it afterwards?

[Boby]

Hello Yiannis,

I think that even setting RadDocument.DocumentContentChangedInterval to something larger is not needed, as the time is tracked with a DispatcherTimer, which doesn't tick when the UI thread is busy - and you are most probably doing the long operations on the UI (main) thread.

Regards,
Boby
Progress Telerik

[Yiannis]

Hello Boby,

Thanks for taking the time to explain. I think this behavior covers our needs completely. We can now change any content without visually affecting the selection, caret position and scroll offsets.