Posted 14 years ago by NSXDavid
Avatar
One way I am attempting to use SYntaxEditor is for a type of console output. The behavior I'm trying to get is that as data comes from the app, it is appended to editor document. I want it to automatically scroll as it does this... unless the user has scrolled away from the bottom of the document. Only when at the bottom should it autoscroll.

The AppendText() works, and autoscrolls... but I'm having trouble appending text and keeping it from scrolling. I'm trying to determine if the view is already scrolled to the bottom and if so undo the scroll that AppendText() does. Unfortunately that causes a big visual artifact as it bounces to the bottom and then back.

The things I need help with are:

How to determine if I'm already scrolled to the bottom.
How to appendtext() with out scrolling... or in the alternative, undo the scroll without it visually bouncing like that.

Can this be achieved?

-- David

Comments (13)

Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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.


Actipro Software Support

Posted 14 years ago by NSXDavid
Avatar
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
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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):
bool isAtBottom2 = (editor.SelectedView.DisplayLines.Count -
    editor.SelectedView.VisibleDisplayLineCount <= editor.SelectedView.FirstVisibleDisplayLineIndex);


Actipro Software Support

Posted 14 years ago by NSXDavid
Avatar
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
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
Yes, set editor.Caret.BlinkInterval = 0.


Actipro Software Support

Posted 14 years ago by NSXDavid
Avatar
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
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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.


Actipro Software Support

Posted 14 years ago by NSXDavid
Avatar
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]
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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.


Actipro Software Support

Posted 14 years ago by NSXDavid
Avatar
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?
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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:
editor.Document.AppendText(text, editor.Caret.Offset != editor.Document.Length);


Actipro Software Support

Posted 14 years ago by NSXDavid
Avatar
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
Posted 14 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar
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.


Actipro Software Support

The latest build of this product (v2018.1 build 0341) was released 6 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.