PageUp/PageDown does not scroll exact one page when using WordWrap #253
Labels
No labels
Area-Accessibility
Area-Build
Area-CodeCompletion
Area-Document
Area-Documentation
Area-Editing
Area-Folding
Area-Highlighting
Area-i18n
Area-Indentation
Area-NetFx
Area-Rendering
Area-Search
Area-Snippets
dependencies
duplicate
Feedback Needed
help wanted
invalid
Issue-Bug
Issue-Discussion
Issue-Enhancement
Issue-Performance
Issue-Question
on-hold
Resolution-Answered
Resolution-By Design
Resolution-Duplicate
Resolution-Fixed
Resolution-Won't Fix
Up-for-Grabs
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-icsharpcode/AvalonEdit#253
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When navigating through keys PageUp/PageDown and text in “VisualLines” contains wrapped lines, next scrolled page does not continue where previous finished (e.g. last line in previous page was 10 and first line in next page is 15). Cursor is below the current view area and therefore scroll is further as expected. Test performed in ICSharpCode.AvalonEdit.Sample.exe (WordWrap = true).
I’m I missing something, or is there any workaround how to keyboard scroll exact page (the same way like scroll through scrollviewer)?
Best regards,
Paul
Additional clarification:
Wrong page scroll occurs when visual lines are presented for the first time. If user navigates at the beginning of the document (e.g. CTRL+Home) and scroll again to previous place the caret is pointed correctly. If user wants scroll again and the cursor is again positioned incorrectly than operation (navigation top CTRL+Home and back) will correct last wrong caret position.
I found UpdateAugmentedData() returns different node Height in case the line was already presented in visual lines. Because of this, method textView.GetDocumentLineByVisualTop(yPos1) (in method GetUpDownCaretPosition in class CaretNavigationCommandHandler) calculates wrong desired line number and therefore caret is on wrong place.
Unfortunately I don't understand everything to provide additional information.