IntraLine Adornment causes incorrect scrolling

SyntaxEditor for WPF Forum

Posted 7 years ago by Erwin Liong
Version: 17.2.0661
Platform: .NET 4.5
Environment: Windows 10 (64-bit)

To reproduce:
1. In Actipro's Sample Browser, navigate to Adornments 9 - Intra-Line Code Lens.
2. Delete all the contents.
3. Copy 200 lines of the following content into clipboard:
public delegate1 void ProcessBookDelegate(Book book);
4. Paste clipboard into Syntax Editor.
5. Observe: The caret is at the end of the document and line 200 is in view.
6. Delete all contents.
7. Copy 200 lines of the following content into clipboard. Delegate has associated adornment:
public delegate void ProcessBookDelegate(Book book);

Actual: The caret is still at the end of document but is pushed out of viewport. On my monitor, I am seeing Lines 125~Line 168 and their associated adornments.
Expected: The caret is at the end of document and the visible viewport can accomodate the line where the caret is at (Line 200).

Note: I have tried ScrollToCaret for this particular scenario. ScrollToCaret would work but it will break another scenario where I use mouse wheel or scroll bar to change my viewport. ScrollToCaret forces the viewport to contain the caret and is NOT what I needed.

Is there a way to workaround this or a fix for this?

Thank you in advance.



Erwin Liong

Comments (3)

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

Hi Erwin,

Thanks for reporting this.  This is a particularly tricky issue because right now, our view line layout logic starts at the top anchor line (view.FirstVisiblePosition) and lays out in a downward fashion from there.  If some change occurs that triggers a layout (whether it be due to intra-line adornments getting injected from parse results, or just the user scrolling the vertical scrollbar), we don't know why the layout occurred and the anchor position continues getting used.  

I think the only fix for this would be to refactor the line layout logic completely, and have it support the anchor being anywhere within the view, not just at the top.  That way it could try and fix that line in a certain spot and lay out lines above and below to "fill in."  This would require major work though and isn't something we can do right now.  We do plan on getting into possibly refactoring all the view line rendering and layout logic in the next few months, and perhaps this is something we can address there.

In the meantime, the ScrollToCaret workaround might work, but perhaps you do it in response to the parse data changed event?  Or at least only the first parse data change event you get for the document?  That way it might not conflict with mouse wheel scrolling as much.

Actipro Software Support

Posted 7 years ago by Erwin Liong

Hi Actipro, 

When will this be fixed? 

Thanks in advance. 

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

Hi Erwin,

I'm not sure if you've been following our blog, but we've announced we're working on a major refactoring of SyntaxEditor's internals and are improving a lot of feature areas along the way.  More on that here:

One of those enhancements was how view lines are arranged.  We have a much more robust mechanism now for laying out lines.

We haven't tested your particular scenario in SyntaxEditor vNext yet since we don't yet have the infrastructure in place to trigger the scenario.  But maybe write back in a couple months and we'll take a look at it again.  I'm not sure if the updates we made would automatically handle it, but if not, I think we can probably take advantage of some new features in our line arranging logic to improve it.

As for a release date of SyntaxEditor vNext, it's a massive undertaking and is likely several months out yet.

Actipro Software Support

The latest build of this product (v24.1.2) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.