Databound SyntaxEditor loses scroll position on text change.

SyntaxEditor for WPF Forum

Posted 5 years ago by Andrew Hanlon
Version: 14.2.0610
Avatar

The SyntaxEditor loses the scroll position on all databinding changes. This can be demonstrated in the latest sample application. How can this be prevented / worked around? I am using the syntax editor to display some auto-generated code, and every minor change scrolls the document to the very top.

Thanks - Andrew

Comments (7)

Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 5 years ago by Andrew Hanlon
Avatar

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.

[Modified 5 years ago]

Posted 5 years ago by Andrew Hanlon
Avatar

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

Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 5 years ago by Andrew Hanlon
Avatar

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

Answer - Posted 5 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Andrew,

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


Actipro Software Support

Posted 5 years ago by Andrew Hanlon
Avatar

Thanks for the fast update and great support!

The latest build of this product (v2019.1 build 0683) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.