Changes - RiscOS 2.0 to 5.19

Of course, the title should have been Changes – RiscOS 2.0 to 5.19 [ROOL admin: I edited the title for you]

I have an application written in BASIC under RiscOS 2 on an A410.

The code is 185K of BASIC and using SYS “Wimp_Initialise”, 200, etc, it still works on the Raspberry Pi. (as it also does on various other hardware and emulated systems) .

I have a copy of the Acorn PRMs (and I think my program conforms to that) and I now also have “The Window Manager” manual. But, so far I have failed to make the program run with any other “last known version”.

Can anyone point me to a list of the changes I need to make to other SYS statements to move from RiscOS 2.0 to 5.19?

But, so far I have failed to make the program run with any other “last known version”.

What happens when you try?

I have a copy of the Acorn PRMs (and I think my program conforms to that) and I now also have “The Window Manager” manual. But, so far I have failed to make the program run with any other “last known version”.

You’re unlikely to want to be passing 500 into Wimp_Initialise: the version number is used to turn features on, and should be the earliest version of the Wimp that you’re OK with, not the most recent. The numbers you’re most likely to want to pass in are 380 for software that needs the nested features of the Wimp, or 300 otherwise.

The biggest change from 2.00 to 3.00 was the requirement to register user messages with Wimp_Initialise or Wimp_AddMessages. The documentation of R3 in the paper PRMs is wrong here: you should pass in a pointer to an empty list (ie. a pointer to the value 0 in memory) if you want to receive all messages; setting R3 to 0 means that you’ll only get Message_Quit. Setting the message list up accurately is a good idea, as it stops wasting the OS’s time paging your app in to send it the more mundane broadcast messages that get sent around the system.

See Wimp_Initialise for more information.

The numbers you’re most likely to want to pass in are 380 for software that needs the nested features of the Wimp, or 300 otherwise. [snip[ setting R3 to 0 means that you’ll only get Message_Quit.

Wasn’t there a subtle change in that giving zero instead of an empty list in one version would return all messages, while in the other version would return only Message_Quit? Or was that wrong as well?

Anything above 300 was causing corruption of the desktop (best fixed by F12 followed by enter – with the program stopped)

But since reading the point about the use of R3 in Wimp_Initialise – and now using a list terminated by a zero word (instead of a zero byte!), I now have have the program running with any valid value on R0

So, Thank you folks. I think I am now getting some progress.

By the way – it is the use of the mouse scroll wheel that I would like (otherwise I am quite happy with “200”)

By the way – it is the use of the mouse scroll wheel that I would like

I don’t think that depends on the value passed to Wimp_Initialise: the information is passed back in an extended form from various Wimp calls. Where, and how, do you want to use it?

(otherwise I am quite happy with “200”)

You really should use 300 and the smallest list of messages that you need. Otherwise, the Wimp will be wasting a lot of time needlessly paging your app in and out so that it can pass on Message_TaskInitialise, Message_SlotSize and the like when they’re just going to be ignored anyway.

I have a number of windows with many (>100) lines of text. It would be so much better if these could be scolled using the mouse wheel.

Point understood. I will work on that.

have a number of windows with many (>100) lines of text. It would be so much better if these could be scolled using the mouse wheel.

Doesn’t that “just work”? If not, then you might need to set the scroll event flags for the window and handle scroll events from Wimp_Poll.

It certainly works in NetSurf with little magic: checking the source, that passes 380 to the Wimp, sets the ScrollRepeat flag for the windows and has scroll event handlers. If you can read C, the easiest handler to spot is ro_treeview_scroll() in the Treeview Module

No. But reading through the PRMs, it appears that you are right -I could have done this long ago.
(Never had a mouse with a scroll wheel on an ARM processor before)

Edit: Two days later. -- Once again, Thanks for the help. (I have it working now)