Scroll wheel and WIMP

How does the WIMP detect a turning scroll wheel?
I’d like the wheel to zoom in and out, rather than to scroll up and down. But I can’t find any poll reason or user message that intercepts a turning scroll wheel.

Your application should receive https://www.riscosopen.org/wiki/documentation/show/Scroll_Request events if your windows are marked to receive them. Probably best to go for the extended scroll request: http://riscos.com/support/developers/riscos6/input/windowscroll.html

If your app windows do have scroll bars, it’d be best to stay consistent with everyone else and scroll. Don’t think it’s made it into Style Guide but use Ctrl+Scroll_Request to zoom in/out.

… use Ctrl+Scroll_Request to zoom in/out.

That’s a simple solution indeed. But it doesn’t explain how the WIMP detects a turning scroll wheel.

Edit:
Only now I see the link to the WindowScroll module. Thanks, I’ll investigate.

But I can’t find any poll reason or user message that intercepts a turning scroll wheel.

Assuming that you have the “Window Should Use Extended Scroll Requests” flag set in the Extra Window Flags byte (bit 1 at offset 39 of the Wimp_CreateWindow block), then they arrive as Extended Scroll Requests in the usual way through reason code 10 of Wimp_Poll.

Whilst the page on Extended Scroll Requests above is correct in as much as it says that you can determine the type of request by looking at the bottom two bits, it’s also not that helpful in understanding what the scroll values mean. Remember that existing values are

For autoscroll, those bottom two bits are zero and you start to see multiples of +/- 4 arriving in the scroll offset fields (eg. 4, 8, 16, 32 …) to indicate the number of “extended scroll” events which are being sent in. It’s documented better in the RISC OS Six PRM as these events apply to Select 2 onwards and RISC OS 5.27 onwards.

So you can do something like this in your scroll event handler:

CASE poll_block%!24 OF
WHEN 1  : REM One Row Down
  distance% = + RowSize%
WHEN -1 : REM One Row Up
  distance% = - RowSize%
WHEN 2  : REM One Page Down
  distance% = + PageSize%
WHEN -2 : REM One Page Up
  distance% = - PageSize%

WHEN 3, -3 : REM We don't support Autoscroll

OTHERWISE : REM An Extended Scroll Request
  IF poll_block%!24 > 0 THEN
    distance% = (poll_block%!24 >> 2) * RowSize%
  ELSE
    distance% = -((-poll_block%!24) >> 2) * RowSize%
  ENDIF
ENDCASE

(I’ve just translated this from C, so there could be errors)!

Note that here, it’s using the scroll wheel to scroll by one row per wheel click. However, you’re at liberty to do whatever you like with the shifted values calculated in the OTHERWISE block, such as using them to trigger zoom operations.

ETA: Though, as Stuart says, it would be friendly to use a Ctrl modifier on this to stay with the standard RISC OS behaviour of “scroll wheel scrolls”, which is what the pseudo-code above actually does.

… you’re at liberty to do whatever you like with the shifted values calculated in the OTHERWISE block, such as using them to trigger zoom operations.

This looks like what I was looking for. I’ll let you know if I get it working (or not). Thanks.

PS. One thing to mention here: you’ve obviously got to turn on Scroll Events as well (either bit 8 or 9 of the normal window flags), and then handle normal scrolling for yourself in the window (if you aren’t already doing so).

If this is Game of Life, then it gives you the opportunity to have scrolls in the window aligning grid rows and columns with the edge of the window as they go.

Thanks Steve, but the problem is that I can’t manage to let the window react on the scroll wheel. It does react on dragging the scroll bars or clicking the scroll icons, and I even managed to zoom in and out by clicking those icons, but when I turn the scroll wheel, nothing happens.

I’ve created the window with a template editor. Both ‘Extended scroll request’ and ‘Auto-repeat’ are ticked (clicking ‘Debounced’ doesn’t help either). Obviously, I’m missing something, but what?

Tried using ReportPoll to see what you are being fed?

No idea – it “just works” for me (on a recent-ish 5.29).

Two questions:

1. How is the Scroll wheel set up in the Mouse section of Configure?

2. Are you using something like HID to fiddle with the native OS support for scroll wheels? ISTR that this went to great lengths to present scroll wheel use as normal scroll events, so that applications which didn’t handle extended events would still work. The OS does the same if the “extended” flag isn’t set.

… The OS does the same if the “extended” flag isn’t set.

The mouse is configured to ‘Line multiple’ and ‘Window under the pointer’.
HID’s mouse support is switched off.

But unticking ‘Extended scroll request’ in the template editor did the trick – as opposed to what I expected. Thank you for all the suggestions.

But unticking ‘Extended scroll request’ in the template editor did the trick – as opposed to what I expected. Thank you for all the suggestions.

If unticked it lets the system (the WindowScroll module) handle the stuff.
Ticked, it let you handle the stuff yourself in the Scroll request events. For example in KinoAmp I let the wheel control the sound volume and in DigitalCD, you can use it on various sliders to control them.

Okay, the way I understand things now is that if you want the scroll wheel to do other things than scrolling, you have to intercept the entire scroll event. That’s all right for the task that you’ve assigned to the scroll wheel, but all other tasks (dragging the scroll bar, clicking the scroll icons, clicking in the space between scroll bar and scroll icons) must then be reprogrammed manually.

It would be nice if the WIMP detects a turning scroll wheel and reacts to that, without loosing control of all other possible scroll tasks – if you can follow me (I hardly can follow myself, after this delicious bottle).

It would be nice if the Wimp could handle the two scroll wheels and 7 buttons of my MX Master 3 mouse.

How many hands does that mouse take to operate 8-)

You actually need one less hand on the keyboard as the second scroll wheel is set up to zoom, which would otherwise be ctrl + scroll wheel – very handy!

Okay, the way I understand things now is that if you want the scroll wheel to do other things than scrolling, you have to intercept the entire scroll event. That’s all right for the task that you’ve assigned to the scroll wheel, but all other tasks (dragging the scroll bar, clicking the scroll icons, clicking in the space between scroll bar and scroll icons) must then be reprogrammed manually.

Yes, but it’s not that hard to do. The code for WinEd, which was added when it was apparent that the scroll wheel wasn’t doing anything in windows where extended scroll events were selected, is as follows:

/**
 * Handle scrolling in a window.
 *
 * \param *event      Pointer to the event_pollblock for the scroll.
 * \param col_size    The size of a horizontal scroll, in OS units.
 * \param row_size    The size of a vertical scroll, in OS units.
 * \param top_margin  The size of the pane/margin at the top of the window, in OS units.
 */
void scroll_window(event_pollblock *event, int col_size, int row_size, int top_margin)
{
  scroll_rq *scroll = &(event->data.scroll);
  int width, height, error, distance;

  /* Add in the X scroll offset. */

  distance = 0;
  width = scroll->openblock.screenrect.max.x - scroll->openblock.screenrect.min.x;

  switch (scroll->direction.x)
  {
    case 1: /* One Column Right */
      distance = +col_size;
      break;

    case -1: /* One Column Left */
      distance = -col_size;
      break;

    case 2: /* One Page Right */
      distance = +width;
      break;

    case -2: /* One Page Left */
      distance = -width;
      break;

    case 3:
    case -3:
      /* We don't support Auto Scroll. */
      break;

    default: /* Extended Scroll */
      if (scroll->direction.x > 0)
        distance = (scroll->direction.x >> 2) * col_size;
      else if (scroll->direction.x < 0)
        distance = -((-scroll->direction.x) >> 2) * col_size;
      break;
  }

  scroll->openblock.scroll.x += distance;

  /* Add in the Y scroll offset. */

  distance = 0;
  height = (scroll->openblock.screenrect.max.y - scroll->openblock.screenrect.min.y) - top_margin;

  switch (scroll->direction.y)
  {
  case 1: /* One Rown Down */
    distance = +row_size;
    break;

  case -1: /* One Row Up. */
    distance = -row_size;
    break;

  case 2: /* One Page Down */
    distance = +height;
    break;

  case -2: /* One Page Up */
    distance = -height;
    break;

  case 3:
  case -3:
    /* We don't support Auto Scroll. */
    break;

  default: /* Extended Scroll */
    if (scroll->direction.y > 0)
      distance = (scroll->direction.y >> 2) * row_size;
    else if (scroll->direction.y < 0)
      distance = -((-scroll->direction.y) >> 2) * row_size;
    break;
  }

  scroll->openblock.scroll.y += distance;
  if ((error = ((scroll->openblock.scroll.y) % row_size)))
    scroll->openblock.scroll.y -= ((distance > 0) ? row_size : 0) + error;

  Wimp_OpenWindow(&(scroll->openblock));
}

It’s not that complex (although sorry, but I’m not converting it to BASIC). It’s also fairly generic; that same routine is called by all of the different windows which can scroll (windows being edited, browser windows, the stats window, etc), IIRC.

The benefit of handling scroll events yourself is that you can ensure that the scroll units line up with your window’s contents. If this is Game of Life, then you could have row/column scrolls move one row or column of your grid; have page scrolls line up the leading grid square edge in the direction of travel… that kind of thing. It’s not a massive feature, but adds a quality feel when the user is navigating the windows. That’s what the error calculation is doing on the Y scroll, as WinEd only has things that matter in the Y direction; you can do the same on the X scroll, though.

Thanks Steve, I now got it working (more or less), except for one important thing: the scroll bars can no longer be dragged. Nothing in the scroll request block% seems to get updated when I try to drag a scroll bar. And, of course, I can’t miss that feature, especially the one that lets you dragging the entire window around when click-dragging Adjust on one of the bars.

Nothing in the scroll request block% seems to get updated when I try to drag a scroll bar.

This is off the top of my head and completely unchecked, but don’t scroll bar drags come in via the usual Open Window Request event, with updated X and Y Scroll Offsets?

[…] but don’t scroll bar drags come in via the usual Open Window Request event, with updated X and Y Scroll Offsets?

Yes, but I can’t drag them any more. They’re glued to their location if I click-drag them. Then pointer moves, yet not the scroll bar, while all other scrolls now work as intended.

Yes, but I can’t drag them any more. They’re glued to their location if I click-drag them

Things I would try at this point:

Check the scroll offsets returned via WindowOpen – are they before or after the drag attempt?
I’m thinking you mey need to make changes before opening the window

Temporarily turn off the code you have related to scrolling. I’m wondering whether something in your code elsewhere is undoing the change sent via WindowOpen.

All this might be completely wrong of course.

Temporarily turn off the code you have related to scrolling.

Yes, that helps. But I already noticed that when I only implemented vertical scrolling so far. Dragging the vertical scroll bar then was no longer possible, while the horizontal one just behaved normally – until I implemented horizontal scrolling as well.
Remember that all other scroll requests behave obediently, like clicking the scroll icons, clicking in the space between scroll bar and scroll icons as well as mouse wheel scrolling – even horizontally (with Shift held down).

Here’s the routine:

DEF PROCscrollrequest(w%,xscroll%,yscroll%)
IF w% <> main% THEN ENDPROC
:
block%!0 = main%
SYS "Wimp_GetWindowState",,block%
windowx% = block%!12 - block%!4
windowy% = block%!16 - block%!8
xoffset% = block%!20
yoffset% = block%!24
:
SYS "OS_Byte",121,0 TO ,key%
:
IF key% = 1 THEN PROCcellgrow(yscroll%/4) : ENDPROC  : REM Ctrl-key invokes zooming
IF key% = 0 THEN
  IF ABS(yscroll%) = 4 THEN scx% = xoffset% - (cellsize% * yscroll%) : REM Shift-key invokes horizontal scrolling
 ELSE
  CASE yscroll% OF
    WHEN -4,4 : scy% = yoffset% + ((cellsize% * 2) * yscroll%)
    WHEN -2,2 : scy% = yoffset% + (yscroll% / 2) * windowy%
    WHEN -1,1 : scy% = yoffset% + (cellsize% * yscroll%)
  ENDCASE
  CASE xscroll% OF
    WHEN -2,2 : scx% = xoffset% + (xscroll% / 2) * windowx%
    WHEN -1,1 : scx% = xoffset% + (cellsize% * 2 * xscroll%)
  ENDCASE
ENDIF
:
PROCopenwindow(main%)
ENDPROC

xscroll% and yscroll% are set by poll request 10: PROCscrollrequest(block%!0,block%!32,block%!36)
scx% and scy% are the new scroll offsets that get processed in PROCopenwindow(main%)

Do you set scx% and scy% when receiving Open Window Request events if that also calls PROCopenwindow(w%)?

Yes, I forgot to mention that in the above post. Now corrected.

Can you trace what wimp poll; returns you are handling after a drag? I am startng to suspect that you might get a window open followed (or preceeded) by a scroll event, and that somehow the handlers for them are cancelling themselves out.

When I (try to) drag a scroll bar, the wimp poll detects reason code 18. The user message received is 16.
But exactly the same is true for clicking the scroll icons, or clicking the space between scroll bar and scroll icon, which does work.
By the way, my PROCreceive doesn’t handle User message 16 (= &11).