I thought this is what the ScrollLock key was for, but wasn't aware that Apple keyboards don't have one. http://en.wikipedia.org/wiki/Scroll_lock
I think that in some applications Page Up/Down will reposition the caret, but by using a modifier such as Control with Page Up/Down, it would merely scroll the viewport. Chris On 16 September 2010 19:26, Greg Brown <[email protected]> wrote: > 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... > >
