Databound SyntaxEditor loses scroll position on text change.

Hi Andrew,

Thanks for writing.  The problem here is that the databinding update effectively completely replaces the document's text.  Whenever the document text is completely programmatically replaced, SyntaxEditor is set up to scroll back up to the top since it's assuming that a new document has been set.

What would you suggest we do here to help handle this special case?  Even with data binding, we don't know if the data binding update is effectively for completely new document text or just a simple change.

That is a good point - If the databinding was being used to show multiple documents, then you wouldn't want the document to stay scrolled when changing.

However, in my opinion these represent very different databinding scenarios: a 'document' vs the text of the document.

In the normal case, I would expect the SyntaxEditor.Text databinding to behave in a similar fashion to databinding on a TextBox or RichTextBox, which both preserve the scroll position.

In any case, is there a workaround possible to prevent the scroll position from changing? Or a way to read the scrollposition before the text changes and set it afterward? 

Edit: I looked at reading the visual tree to find the vertical offset directly, however it appears that the control does not use a standard scrollviewer.

Okay, I found a work-around which is to capture the View.FirstVisiblePosition within the DocumentTextChanging event and then set the FirstVisiblePosition in the DocumentTextChanged event. This seems to work fine, but please let me know if there is a better solution.

Thanks, Andrew

Hi Andrew,

Yes that is the only workaround for now.  We will look into seeing if we can improve this scenario to do that in a more automated way.  I did test regular TextBox controls and they seemed to retain the scroll position, so we probably should as well in data binding scenarios.  As you said, the document could be bound instead if the developer wanted to use a different "document" text.

Thank you kindly. For now this workaround is fine, and has no performance or visual artifact issues.

Hi Andrew,

We have updated our code for the next build to retain the scroll position on data binding changes.

Thanks for the fast update and great support!