Block select and type causes view to jump to top of file

[zaksmolen]

I recently updated to a current version of AvalonEdit, and it seems like some of the block select issues have been resolved. Delete now deletes all lines, not the first, though block select still remains so slow as to be almost unusable with large selections.

One issue that seems to be new is that if you type in a block selection, it causes the view (and caret) to jump to the top of the file. I confirmed that this behavior exists in sample application in the latest code as well. This means that block select is almost impossible to use, because the view jumps away from where you're typing.

[zaksmolen]

I can't seem to get it to happen consistently, but it seems like having it full-screen seems to make it happen more often.

[zaksmolen]

I did confirm that it's happening in the code. In RectangleSelection.cs line 334 textArea.Caret.Position = textArea.TextView.GetPosition(new Point(GetXPos(textArea, pos), textArea.TextView.GetVisualTopByDocumentLine(Math.Max(startLine, endLine)))).GetValueOrDefault(); The position gets set to line 1 col 1 even though it was previously the top of the selection, line 7 col 8

Here are some of the values in debugging

It seems that textArea.TextView.GetPosition() returns null, so it's getting the default value

[zaksmolen]

I'm just sort of blindly debugging here since I just got the AvalonEdit source set up for the first time today and this is my first time looking into it. TextView.GetVisualLineFromVisualTop() is returning null within the TextView.GetPosition() call and this comment in there seems suspect:

			// TODO: change this method to also work outside the visible range -
			// required to make GetPosition work as expected!

[siegfriedpammer]

Would it be possible for you to provide step by step instructions on how to reproduce this? Thank you very much!

[zaksmolen]

Testing again I can't replicate it... I did make a few tweaks related to block select (I believe that I fixed the slowness issues) and it might have fixed it as a side effect. I'll look into putting my changes into a pull request soon.

On Mon, Mar 8, 2021 at 12:04 PM Siegfried Pammer [email protected] wrote:

Would it be possible for you to provide step by step instructions on how to reproduce this? Thank you very much!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/icsharpcode/AvalonEdit/issues/243#issuecomment-792905112, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC7P4IGYBU4NNKLVZTGVFS3TCT7STANCNFSM4RNONNRA .

[zaksmolen]

Ah, looking at my changes I think I see what probably fixed it: in RectangleSelection.cs it used to have this around line 334: textArea.Caret.Position = textArea.TextView.GetPosition(new Point(GetXPos(textArea, pos), textArea.TextView.GetVisualTopByDocumentLine(Math.Max(startLine, endLine)))).GetValueOrDefault();

The problem with that is if it's null, the position gets set to default, i.e. top of document. I threw a null check in and didn't overwrite the caret position if it was null.

TextViewPosition? calculatedPositon = textArea.TextView.GetPosition(new Point(GetXPos(textArea, pos), textArea.TextView.GetVisualTopByDocumentLine(Math.Max(startLine, endLine))));
                if (calculatedPositon != null) {
                    textArea.Caret.Position = calculatedPositon.GetValueOrDefault();
                }

I'm removing the debugging stuff from my output and I'll put in a pull request with this and the block select slowness fix

[goswinr]

I also had an issue with the new block selection that happened only with some font sizes, for example 17.5 ( font Consolas). The last line of the block would not be selected anymore after delete key press.

[zaksmolen]

I just created pull request 269 which I believe contains the fix for this, as well as the slowness issues seen in larger block selections