Editor as Console

Actually in the most recent release we added overloads to methods like AppendText where they accept a boolean param indicating whether to scroll. Check that out.

To find if they are at the bottom you'd have to do some math with the count of display lines in the EditorView, the view's FirstVisibleDisplayLineIndex and VisibleDisplayLineCount properties.

I'll grab the latest release!

As for seekign the bottom, I tried this:

bool isAtBottom2 = (editor.SelectedView.FirstVisibleDisplayLineIndex + editor.SelectedView.VisibleDisplayLineCount == editor.Document.Lines.Count - 1);

Doesnt' seem to work right. DId I miss somethng?

-- David

Make sure you check display lines not document lines too (in case word wrap is on).

Maybe something like this (I didn't test it):

Good point, word wrap is on actually. I'll try that... in the meantime... is there a way to supress the rendering of the blinky caret?

-- David

Yes, set editor.Caret.BlinkInterval = 0.

So the technique to determine if I'm at the bottom or not seemed to work at first, but wasn't robust... the moment I started messing with where I'm scrolled to it'd get confused if it was a the bottom or not. So I added a label that displayed the values and I can see the problem:

It appears that FirstVisibleDisplayLineIndex gives strange values. It can be just plain wrong in ways that are hard to understand. It'll start off correct.. then you start doing things like scrolling up (press up arrow on scroll bar) and it'll stil lbe right.. but then scroll with the mouse wheel and it's wrong... ctrl-home and ctrl-end and it's still wrong... then sometimes it seems to correct itself... I can't figure out what's going on. I am displaying all the values in that equation and I can see that DisplayLines.Count is always right, and VisibleDisplayLines.count is right, but FirstVisibleDisplayLineIndex can be wrong. Heck one time I scrolled to the end of a 900 line document (with 9 lines visible) and FirstVisibleDispalayLIneIndex was 0! Moved around some and it corrected itself.

Help?

-- David

Ahh this sounds like a bug that we fixed for the upcoming maintenance release which is:

Fixed a bug where the FirstVisibleDisplayLineIndex property wasn't updated by the time the ViewVerticalScroll event fired in a certain situation and same with the related horizontal scroll event.

The fix will be out soon.

Yeah, I just figured that out and corrected for it by using a timer to update the debug label.

So the IF statement does determine if the view is scrolled to the bottom correctly... but the function:

editor.Document.AppendText("\n" + LineOfText,!isAtBottom);

Will still scroll even if isAtBottom is false. Seems to be related to where the caret is or something maybe? Is that bool argument stupposed to supress scrolling or is that dependent on other factors?

-- David

ps. Appears to be that if the caret is at the very end of the file, it'll cause the view to scroll even if you pass false. If it's anywhere else, it works as expected.

[Modified at 09/08/2005 06:48 PM]

The bool param controls whether the caret moves when text is inserted.

However if text is inserted before the caret, it will move the caret by the length of the text. But the caret will still stay in its relative location to the text insertion offset.

So...... that means... it scrolls on purpose? My goal is to keep it from scrolling when I do AppendText(). How would I make that happen?

Take a look at the VS.NET Output window. Regardless of what the first visible display line is, it scrolls to the bottom if the caret is at the end of the text. So it's almost like they do something like:

Perhaps they do, though that is not the behavior I would want. The user expects that if they are viewing a portion of the scrollback that it won't just jump to the end for no apparent reason. That is what I am trying to achieve. Does this mean I should sneakily reposition the caret to, say, the beginning of the line, if it happens to be at the very end of the document? Or something like that?

-- David

You could probably just hide the caret and reposition it at the beginning of the first display line whenever the view is scrolled. Let me know if that works for you.