The easiest solution would probably be to have it override the page up/down key press events and determine what the next line should be based on the viewport height.
However, as I mentioned in the other thread, I'm not sure that changing the caret position just because the viewport changes is good UI design. The text editor I use on the Mac (SubEthaEdit) doesn't do it - just like Pivot's TextArea/TextPane, you can scroll the caret out of view using either page up/down or the scrollbar; however, any key press will scroll it back to visible. Eclipse does reposition the caret on page up/down, but not when the user scrolls manually, which, to me, seems inconsistent. However, like the others, a key press brings it back into view. G On Sep 15, 2010, at 9:36 PM, Todd Volkert wrote: >>> - Page Up/Down: go up/down by n elements (bounded by first/last), where n is >>> the size of the current page (for example in a List or a Table with size 20 >>> elements the page here could be 20) ... >> >> Not sure this makes sense. Page up/down is currently handled by ScrollPane, >> which, in most cases, will be used to host a list, table, or tree. So I >> think the current behavior is probably OK. We could certainly revisit this >> later, though. > > Might it make sense to have TextArea override scrollToVisible() to > also update the position of the caret? Though as I think about it, > I'm not sure that would come into play here anyway...
