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

richText.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.

Promoted to ticket #534 and assigned to brian

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.

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.

Ticket resolved in 1.0.42

Used the work around suggested on the SWT Forum

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.