Scroll wheel and WIMP

A few thoughts on this. First, you don’t need to do

block%!0 = main%
SYS "Wimp_GetWindowState",,block%

unless you’re using the window flags, as all of the data for the

windowx% = block%!12 - block%!4
windowy% = block%!16 - block%!8
xoffset% = block%!20
yoffset% = block%!24

is already in the event block that arrives from Wimp_Poll with the Scroll Request event.

Second, how does PROCopenwindow(main%) get the new scroll offsets? Are scx% and scy% globals?

Third, your test for ABS(yscroll%) = 4 here

IF ABS(yscroll%) = 4 THEN scx% = xoffset% - (cellsize% * yscroll%)

as well as your WHEN 4,-4 are wrong. Remember that the value returned is +/-1, +/-2, +/-3 or a value from +/-1 upwards, shifted left two places. It could be +/-4, or +/-8, or +/-12, or …, depending on how much you need to scroll. That’s why I did the “is it +/-1, +/-2 or +/-3? No? Then it must be an extended scroll, so shift it down two bits and process it as a scroll amount” exercise. Your code would fail if the scroll jump was bigger than “one unit”.

To show some code that works, in context, I’ve taken this example here from my pane tutorial and made the following modifications (which you’ll need to replicate yourself in the example files from my site).

First, edit the Main window template, so that scroll events are “Auto-Repeat” and “Extended Scroll Requests” are on. You may also wish to make the work area of the main window bigger, so that it can be scrolled around more.

Then, in the BASIC program, update PROCpoll as follows, to change the poll mask flags and add a handler for Scroll Request events:

DEF PROCpoll
LOCAL reason%

SYS "Wimp_Poll", &3801, b% TO reason%

CASE reason% OF
        WHEN 2      : SYS "Wimp_OpenWindow",,b%
        WHEN 3      : SYS "Wimp_CloseWindow",,b%
        WHEN 6      : PROCmouse_click(b%)
        WHEN 9      : PROCmenu_selection(b%)
        WHEN 10     : PROCscroll_request(b%)
        WHEN 17, 18 : IF b%!16 = 0 THEN Quit% = TRUE
ENDCASE
ENDPROC

Finally, add in PROCscroll_request() as follows:

DEF PROCscroll_request(b%)
LOCAL row_size%, page_size%, distance%

REM Horizontal requests

row_size% = 50
page_size% = b%!12 - b%!4

CASE b%!32 OF
WHEN 1  : REM One Row Down
        distance% = + row_size%
WHEN -1 : REM One Row Up
        distance% = - row_size%
WHEN 2  : REM One Page Down
        distance% = + page_size%
WHEN -2 : REM One Page Up
        distance% = - page_size%

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

OTHERWISE : REM An Extended Scroll Request
        distance% = (b%!32 >> 2) * row_size%
ENDCASE

b%!20 += distance%

REM Vertical requests

row_size% = 50
page_size% = b%!16 - b%!8

CASE b%!36 OF
WHEN 1  : REM One Row Down
        distance% = + row_size%
WHEN -1 : REM One Row Up
        distance% = - row_size%
WHEN 2  : REM One Page Down
        distance% = + page_size%
WHEN -2 : REM One Page Up
        distance% = - page_size%

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

OTHERWISE : REM An Extended Scroll Request
        distance% = (b%!36 >> 2) * row_size%
ENDCASE

b%!24 += distance%

SYS "Wimp_OpenWindow",,b%
ENDPROC

By the way, my PROCreceive doesn’t handle User message 16 (= &11).

That’s the drag and drop protocol. Are you doing something that’s triggering that unnecessarily?

Second, how does PROCopenwindow(main%) get the new scroll offsets? Are scx% and scy% globals?

Yes, they are globals.

Third, your test for ABS = 4 here […] as well as your WHEN 4,-4 are wrong.

Well, 4 or -4 is the value in b%!36 when the mouse wheel is turned. It’s not documented – at least not in the StrongHelp manuals – but I discovered that writing the scroll routine.

By the way, my PROCreceive doesn’t handle User message 16 (= &11).

That’s the drag and drop protocol. Are you doing something that’s triggering that unnecessarily?

Not that I know. Drags and drops are handled in the routines that are called by User message 2 and 3. Only yesterday I discovered, using Reporter, that the wimp poll broadcasts a User message 16 at every scroll attempt. Should I do something with that, or can it be ignored?

That’s the drag and drop protocol.

I wonder whether the Wimp is treating the scroll bars as objects being dragged?
It’s not the message I would expect there however:
https://www.riscosopen.org/wiki/documentation/show/Message_DataRequest

I wonder whether the Wimp is treating the scroll bars as objects being dragged?

I don’t think so, unless the Wimp considers clicking the scroll icons, or clicking the space between scroll bar and scroll icon as drags as well, since it broadcasts a User message 16 on those actions too.

Are you certain about the message number? The docs here say it’s asking for clipboard data, which seems unlikely?
https://www.riscosopen.org/wiki/documentation/show/Message_DataRequest

It might be worth investigating that poll return code 18 (recorded message). The received block contains at offset 4 the task ID of the sender. Identifying the sender might help.

Are you certain about the message number? The docs here say it’s asking for clipboard data, which seems unlikely?

Agreed, apologise. message 16 is Data request (&10), not Dragging (&11). But neither of them should should be broadcasted when doing some scroll action, should they? (Dragging refers to drag and drop, not to dragging a scroll bar.)
I’m going to rewrite my entire program, and try to avoid inconsistencies (all 1000+ of them).

I wonder whether you have something else running on your computer that’s reacting to the scrollbar drag? (e.g. Clipboard handler of some sort.) It might be worth stripping the program down to just the scrolling part and posting it, so it can be tested on someone else’s setup, e.g. mine.

Message 16 is still listed as part of the drag and drop protocol in the online PRM. (It’s not found in the printed RO3 PRM as far as I can see.)

Well, 4 or -4 is the value in b%!36 when the mouse wheel is turned.

It’s a value, but it could be a larger number.

It’s not documented – at least not in the StrongHelp manuals – but I discovered that writing the scroll routine.

I thought that I linked to the RISC OS Six PRM before, which appears to be the best documentation on the extended scroll requests. RISC OS 5 behaves the same.

The TL;DR version is that if either of bits 0 and 1 of the value are set (so -3, -2, -1, 1, 2, or 3), then it’s an “old-style” value which has a fixed interpretation. Otherwise, if bits 0 and 1 are both clear, it’s an extended request and the value should be shifted right two places in order to get the “magnitude” of the required scroll in something that can probably be treated like wheel clicks.

So your +4 or -4 is actually an extended scroll of +1 or -1, which is the smallest unit. If you received +/-8, then it’s +/-2 units, and so on.

I wonder whether you have something else running on your computer that’s reacting to the scrollbar drag?

If all else fails, using MsgMon and Reporter to see what’s sending messages around might be instructive.

Message 16 is still listed as part of the drag and drop protocol in the online PRM. (It’s not found in the printed RO3 PRM as far as I can see.)

No, it post-dates the Acorn-era printed PRM by a couple of years, IIRC, and is documented in Application Notes 240 and 241.

Apologise for the long delay in reply; I was unplugged for some days.

It might be worth investigating that poll return code 18 (recorded message).

When dragging a scroll bar (or at least when trying so), no poll return 18 appears to be broadcasted, neither at other scroll actions.

If all else fails, using MsgMon and Reporter to see what’s sending messages around might be instructive.

MsgMon spits out a lot of information, but remains silent at every scroll action, not only at those of my program. So, I’ve no idea how to use that information to find out why I can’t drag the scroll bars of my program.

I wonder whether you have something else running on your computer that’s reacting to the scrollbar drag? (e.g. Clipboard handler of some sort.)

If that were the case, wouldn’t it affect the scroll bars of other programs too? It must be my program, I’m doing something wrong. If I keep failing to find out what, I’ll try to strip everything but the window and its routines in question, and post the result here.

Well, I finally discovered why I could no longer drag the scroll bars of my program. Dragging those bars broadcasts a “WindowOpen” poll reason. In my program it calls a routine in which the main window is not only opened, but where its dimensions are also set, including the scroll offsets! This caused a static situation, since new scroll offsets hadn’t yet been calculated.
The solution is to calculate those offsets in a scroll routine – and open the window in that same routine, instead of calling the OpenWindow routine.

The only problem remaining is that I can’t get the program react reliably on the mouse scroll wheel. That is, it doesn’t react at all, until I’ve done something magic. No idea what that magic might be, but sometimes it suddenly works, and my mouse scroll procedure gets executed from then on.
The window in question is set to ‘Extended scroll requests’ and bit 1 of block%!39 is set indeed. Any idea?

And now I’ve discovered why my program doesn’t react on the mouse scroll wheel. Surprisingly, it’s not my program this time. It’s the WimpScroll module that comes with !HID. Although I had disabled its scroll wheel support, the module appears to be loaded nevertheless. For some reason it interferes with the WindowScroll module that is part of the RISC OS distribution. RMKilling WimpScroll solved my problem.

For some reason it interferes with the WindowScroll module that is part of the RISC OS distribution.

Two modules trying to do the same task – you know it won’t end well.
Being fair to HID, it was doing things when the OS didn’t know how.