[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform.swt] Re: Scrolling in Text, restoring the state of

Cool; thanks, that seems to work just fine

Paul K

Knut Radloff wrote:

> You should not modify scroll bars of a widget programmatically. The contents will get out of sync on some platforms. Use setTopIndex
> instead.
>
> Knut
> "Paul T. Keyser" <rolarenfan@xxxxxxxxxxxxx> wrote in message news:3EC523D0.3A10BC70@xxxxxxxxxxxxxxxx
> > R2.0.2, WinXP (but same on Win2K) -- have looked over the dozens of
> > threads on "scroll" in the old newsgroup (and the few in this one) to no
> > avail
> >
> > We have a Text widget (same thing as I'm about to describe also happens
> > in our StyledText widget) in a GridLayout with many other widgets.  If
> > enough text is entered (or programmatically set) the vertical scroll-bar
> > appears (word-wrap is set, making it be that no horiozontal bars will
> > appear).  All fine and good, but, when we programmatically update the
> > (Styled)Text widgets, the scrolling "state" changes from whatever the
> > user set it to (it gets restored to "top", in effect).
> >
> > OK, we think, no problem -- we will get all six int-values relevant to
> > the scoll "state" before the update, and after the text is reset, we
> > will restore them using the instance method Scrollable.setValues().
> > That sort of works -- the scroll-bar's "thumb" returns to the original
> > position, but the actual text inside the widget remains at the "top".
> > As soon as the *user* clicks on the thumb (not moving it) the text
> > "jumps" to the correct place.  (Attempted workarounds include playing
> > with setSelection() and getCaretOffset(), which do interesting things,
> > but do not play well with setValues().)
> >
> > What I would like to do is to make that last "jump" happen
> > programmatically -- how is that done? or is this a bug in Scrollable?
> >
> > Thanks,
> > Paul K
> >