In the RichText mods that Brian (I think) posted just over a week ago, adding support for tracking scrollbar events (with hbar and vbar). I've been using it for a week in what I'm doing, and thanks. It works fine when you scroll the view by actually using the scrollbar, but if you hit pagedown or arrowdown to navigate instead, then no Scrollbar.onModify() message happens.
The scrollbar itself is moving as it should, and the richtext works right, but just the key handling isn't triggering the Scrollbars to send an onModify event.
I'm not needing it too bad yet, but sooner or later I'll have to do something about it; in the meantime it probly oughta be tracked.
Simplest possible testcase is, go to flux/fluxText/fan/TextEditor.fan, in the onLoad method after richText is constructed add something like
Great, thanks; changes look good... and it works! cheers.
Seems like this is the only way to fix it, too. Windows controls like RichText apparently have their own scrollbars, which aren't first-class Controls themselves. (There's a separate ScrollBar control, but for reasons going back to 16-bit Windows needing to minimize the number of controls, it isn't used by RichText).
So that leads to some fairly heinous workarounds in libraries like SWT. One that I read about, for instance, is placing scrollbar widgets over top of the native scrollers, and forwarding messages, so as to be able to control look-and-feel of scrollers.
Anyway it got pretty complicated, trying to figure out what to do in the general case. Glad to see we've got a fix that's working.
KevinKelley Wed 15 Apr 2009
In the
RichTextmods that Brian (I think) posted just over a week ago, adding support for tracking scrollbar events (withhbarandvbar). I've been using it for a week in what I'm doing, and thanks. It works fine when you scroll the view by actually using the scrollbar, but if you hit pagedown or arrowdown to navigate instead, then noScrollbar.onModify()message happens.The scrollbar itself is moving as it should, and the richtext works right, but just the key handling isn't triggering the Scrollbars to send an
onModifyevent.I'm not needing it too bad yet, but sooner or later I'll have to do something about it; in the meantime it probly oughta be tracked.
Simplest possible testcase is, go to
flux/fluxText/fan/TextEditor.fan, in theonLoadmethod after richText is constructed add something likerichText.vbar.onModify.add(|Event e| { echo(e) } )(hope that syntax is right, off top of my head). Then open a file in Flux, and on scrollwheel you'll see echos and on pagedowns you won't.
brian Wed 15 Apr 2009
Promoted to ticket #534 and assigned to brian
brian Fri 1 May 2009
I looked into this, and SWT seems broken to me - SWT doesn't fire selection events on the ScrollBar when the keyboard is used.
I asked a question on the SWT newsgroup.
If anyone here knows how to do it, please let me know.
KevinKelley Fri 1 May 2009
I had wondered if the key events are being
consumed by key handling code somewhere. But I couldn't find anything wrong in the fan Peer code.brian Sat 9 May 2009
Ticket resolved in 1.0.42
Used the work around suggested on the SWT Forum
KevinKelley Sat 9 May 2009
Great, thanks; changes look good... and it works! cheers.
Seems like this is the only way to fix it, too. Windows controls like RichText apparently have their own scrollbars, which aren't first-class Controls themselves. (There's a separate ScrollBar control, but for reasons going back to 16-bit Windows needing to minimize the number of controls, it isn't used by RichText).
So that leads to some fairly heinous workarounds in libraries like SWT. One that I read about, for instance, is placing scrollbar widgets over top of the native scrollers, and forwarding messages, so as to be able to control look-and-feel of scrollers.
Anyway it got pretty complicated, trying to figure out what to do in the general case. Glad to see we've got a fix that's working.