Scroll position/moveTo() issue

[gbmhunter]

Hi there.

I am trying to design a "teminal-style" pane which displays incoming data from a serial port, using a StyleTextArea object.

New text is appended onto the end of the StyleTextArea object and removed from the beginning, to keep the total number of characters in the view the same.

I want the user to be able to scroll to say, halfway, and have the text he/she sees remain constant. Keeping the current view constant is easy if I had a way of finding what value moveTo() would result in the current view, as I can count how many characters have been removed, and then call moveTo() again with newValue = oldValue - numCharsRemoved.

If there any way to achieve this functionality? I was able to do it with a normal TextFlow node using the scrollY value (when it was wrapped in a ScrollPane), but since I read that getEstimatedScrollY() on a VirtualizedScrollPane does not work correctly if their are font size changes or wrapped lines, I'm not sure if I can rely on this.

[gbmhunter]

I realise that moveTo() takes an integer, but the actual Y scroll position is a double, but even being able to find the closest integer for moveTo() would be o.k.

[gbmhunter]

I guess a tidy way to do this would be if you could get the Y value of a particular character in the view port within the StyledTextArea, and then call setEstimatedScrollY() after the additions to the end/deletions from the start have been done. As long as that character was still in the text (which is should be), then that should work.

[JordanMartinez]

It sounds somewhat similar to #385.

[gbmhunter]

It is! I hadn't noticed the hit() method before.

I have done a quick implementation, and it mostly works, except that there is a slight drift everytime I call int charAtZeroZero = styledTextArea.hit(0, 0), delete chars from the start, and then call styledTextArea.moveTo(charAtZeroZero).

Is this because moveTo() doesn't move the provided char to 0, 0 (is it more like 10, 10 or something)? And is so, how what I find the exact place (in X, Y) the character provided to moveTo() is placed within the viewport?

[JordanMartinez]

First question we should all ask, which version of RTFX are you using?

It is! I hadn't noticed the hit() method before.

Due to changing the paradigm of the code, this method should probably be renamed to be clearer as to what it does.

Here's my understanding of what you're trying to do.

Text 1
Text 1
------- < Top of area's viewport
aaaa
aaaa
------- < Bottom of area's viewport
Text 2 
Text 2

You want to be able to append Text 2 to the area and/or delete Text 1 while the viewport appears to be unchanged (it still displays the same content as before), correct?

[gbmhunter]

I am using v0.7-M2.

Yes, that is what I am trying to achieve.

[JordanMartinez]

Since you are using wrapped text, the solutions we could implement (by exposing more of VirutualFlow's API) would never fully get rid of that slight shift in the view. For example, you could call area.show(paragraphIndex), but if you are scrolled halfway between lines, it would suddenly shift up/down and display that line (at least, that's my understanding). Then again, I'm not as familiar with VirtualFlow as I'd need to be to give you a good answer.

If you wanted accurate scrolling irregardless of the virtualflow's content, you could look at implementing FXMisc/Flowless#5.

[gbmhunter]

Woah, for some reason I have got it to work "perfectly" by doing:

int beforePos = styledTextArea.hit(0, 10).getCharacterIndex().getAsInt();

// Text insertion/removal goes here

styledTextArea.moveTo(beforePos);

I noticed that is almost worked with styledTextArea.hit(0, 0), except for a slight shift each time. After playing around with the y co-ordinate, styledTextArea.hit(0, 10) seems to work perfectly. I can't seem to break it, but I haven't tried wrapped text yet.

[JordanMartinez]

Closing as this should be resolved for the most part by #418.