Some beginner Wimp programming questions

Hi all,

I’m trying out some Wimp programming stuff and thought maybe I could start a thread to ask some questions of the guys here with more experience. I’ve tried finding some of the answers myself but there aren’t a lot of resources around any more.

Firstly, am I right in thinking that once a window has been created it is not possible to change the background colour of the work area (or any other colour for that matter)? I guess if I want to do that I need to create an icon whose extent covers the visible work area?

Also, I want to try dragging a window by dragging its work area as it doesn’t have a title bar (and it isn’t appropriate to in this context). Ideally I would have other windows update dynamically as it is dragged but I’m not sure how to do that. Presumably once the initial click in the window to start the drag operation is done I have to call Wimp_DragBox and wait for a poll event to say dragging is complete?

Not sure I entirely understand that yet.

I’ll probably have a bunch more questions but that’ll do for now.

Thanks, Simon.

Old versions of the WindowManager/Wimp did not allow you to change window colours. You had to grab the information about the window and icons, delete the window, recreate and then reopen it.

If you are just changing the background colour, using a big icon to cover the entire area is the most compatible way of doing this. Also it is probably the simplest way.

There is a Wimp_DragBox type for dragging windows but I have never tried it. Someone else may be able to help more about this one. Just be aware that once you get to this stage you will not be getting any click events to your window background. The click event will be to your big icon you used to cover it. That icon should have its type set to allow dragging.

Old versions of the WindowManager/Wimp did not allow you to change window colours. You had to grab the information about the window and icons, delete the window, recreate and then reopen it.

However, <forget that – it was drivel>

Far easier to just draw the background yourself on the redraw event!

Simon asked

[is it] possible to change the background colour of the work area?

Yes, two ways – the obvious way that has worked since 1987, and the not-so-obvious way that was introduced in RISC OS 3.8 in 1998.

The obvious way

Create the window with flags b4 clear, which means the Wimp will poll you with a Redraw event whenever any part of the window is revealed (and before it draws any icons). You can then draw anything you like in there (eg setting the background colour and doing a CLG). If you’re filling the entire window then you don’t need the Wimp to draw any background colour first, so you create it with background colour 255, meaning none.

The oh-yes-we-forgot-about-that way

Create the window with an indirected title and set b0 of the Extra Flags byte. Now set your title validation string to C///00FF77 and enjoy your lime green window background. You can change the contents of the validation string at any time.

I want to try dragging a window by dragging its work area as it doesn’t have a title bar

This is dragtype 1 for Wimp_DragBox. When you look it up you’ll see you can also resize a window with dragtype 2.

enjoy your lime green window background.

“Enjoy”???

Fortunately, my meal is sufficiently far down that it isn’t plastered on the keyboard. < shudder >

What’s wrong with green?!

Rabbit food. 🥦 🥗

Give me yellow ¹, orange ², red³, and three shades of brown ^{4 5 6}.

¹ Chips 🍟

² Beans 🌬️

³ Ketchup 🍅

⁴ Burger 🍔

⁵ Toast 🍞

⁶ TEA! ☕

Thanks for the replies. :)

I thought I’d try for now using Wimp_UpdateWindow to paint the different background colours over the window when the pointer enters and leaves. I wrote a routine for handling redraw requests from Wimp_Poll and which works well. So I tried the same strategy with Wimp_UpdateWindow (so I didn’t have to wait for the action) but it seems that the rectangles that I am getting returned from Wimp_GetRectangle aren’t just covering the visible portion of the the window. They seem to be returning:

• x0 = the correct X offset of the left side of the window
• y0 = the correct Y offset of the bottom of the window
• x1 = x0 + window width
• y1 = x1

I can use the x0 and y0 values to draw my own rectangle that covers the window but the trouble with that is that it doesn’t account for the window not being at the top of the stack. But the same code does work when Wimp_RedrawWindow/GetRectangle are invoked in the redraw request handler.

Can anyone see if I am using Wimp_UpdateWindow/GetRectangle correctly in this context?
Many thanks.

@ Simon,

Your code looks correct to me, except the portion where you’re calling Wimp_GetRectangle before you redraw a portion of the window. So, it’s possible that it’s just returning “there are no more areas that needs update”.

Have you tried to invert the two sections in your while(moreToDraw) {} ? (file SALib.cc.window)

Basically call wimp_get_rectangle at the end of your while.

Just my 0.5c, hope this helps,

My recollection is that you call Wimp_UpdateWindow to tell the wimp what part of your work area is now invalid and needs to be redrawn (as you know what has changed) and then behave similarly to a redraw request. On return from UpdateWindow the Wimp will tell you the first area to be redrawn and subsequent calls to GetRectangle will return any further areas to be redrawn (or none if your window is on top). This is not done in the Wimp_Poll loop where you do a redraw but at the point in your programme when you know something has changed. A normal redraw request will clear the affected area of the screen (if the relevant bit is set) but UpdateWindow does not. For example:

    6566 :   SYS "Wimp_UpdateWindow",,block% TO flag%
    6586 :   WHILE flag%
    6694 :         SYS "Wimp_SetColour",7+48
    6698 :         MOVE x%-300-192-20*i%-10-30,y%+79+Dy%
    6702 :         MOVE x%-300-192-20*i%-10-0,y%+139+Dy%
    6706 :         PLOT &A5,x%-300-192-20*i%-10-60,y%+139+Dy%
    6710 :         MOVE x%-300-192-20*i%-10-30,y%+89+Dy%
    6714 :         MOVE x%-300-192-20*i%-10-0,y%+149+Dy%
    6718 :         PLOT &A5,x%-300-192-20*i%-10-60,y%+149+Dy%
    6734 :     SYS "Wimp_GetRectangle",,block% TO flag%
    6738 :   ENDWHILE

Can anyone see if I am using Wimp_UpdateWindow/GetRectangle correctly in this context?

You’re not.

UpdateWindow is exactly like GetRectange – if it returns a non-zero in R0 then it has updated the rectangle in the block and set the clip rectangle. You are ignoring this initial rectangle and then calling GetRectangle and drawing regardless of its return (when there’s no clip rectangle).

Follow Chris’s advice above – if <UpdateWindow> then loop {<redraw> and result=<GetRectangle>} until result=0.

Many thanks guys. I got the Wimp_UpdateWindow loop working with your help.
I think I was originally confused by the wording of Wimp_UpdateWindow in the ROOL Wiki suggesting that the return value of R0 is corrupt and not that it contains the first rectangle data like Wimp_RedrawWindow.

I had a couple of other bugs in the code. I was using the visible area rectangle to plot the rectangles instead of the graphics window dimensions and I also was using relative plotting instead of absolute.

Working on getting the dragging working now. Getting there… :)

suggesting that the return value of R0 is corrupt

Well, technically it isn’t wrong. ;)

But, yeah, that was nonsense. I’ve fixed it.

Got it working!

Thanks. I’m sure I’ll have a million more questions coming up soon. :)

@Rick thanks. To be fair it says the right thing in the proper PRM documents, I just didn’t look at the time.

To be fair it says the right thing in the proper PRM documents, I just didn’t look at the time.

Part of the art of programming is knowing which documents to consult.

There’s the RISC OS 3 PRM in 4 printed volumes, also accessible online I believe.
There’s the RISC OS 3 PRM Volume 5A, corrections, updates for version 3.6 etc, and the index volume for all 5 of those.
Those refer explicitly to RISC OS Version 3.

There’s the printed “Programmers Reference Manual, The Window Manager”, which refers to the Select/Adjust branch of RISC OS (some identified as version 4.xx and as version 6, where xx is something greater than 03).

There’s the ROOL Wiki, which is aimed at RISC OS version 5.

Version 5 is the only version currently being developed, and is the version used on all rPi’s, and many other systems.
VRPC is an emulator which runs the Select/Adjust branch of RISC OS, and can run V5.
RPCEMU usually runs V5, or 4.03.

Most of the content is the same for all versions, but it’s easy to trip over small differences, depending on which version of RISC OS you are running on. Some have already been mentioned here.

There’s the […] There’s the […] There’s the […]

It’s okay.
Running away screaming is an option. ;)

Don’t forget The Applications Tutorial and Listings Book, available over at www.dragdrop.co.uk with, which you may find very useful.

Hi all, back again. 😄

Is it possible for an icon (with an outline font) to have multi-coloured text?
Or would different colours need to be different icons?

Thanks. 👍

Version 5 is the only version currently being developed, and is the version used on all rPi’s, and many other systems.

Excuse me… RISC OS Pyromaniac is also very much being developed.

Part of the art of programming is knowing which documents to consult.

RISC OS Pyromaniac changes are documented here: https://pyromaniac.riscos.online/pyromaniac/prm/index.html

There’s also the RISC OS Select documentation which documents the RISC OS Select changes, which you’ll probably find somewhere like here: http://www.riscos.com/support/developers/riscos6/

You will find my discussion of why this state of affairs is insane, and how it should be addressed here to harmonise the documentation with community accessible documentation: https://www.iconbar.com/articles/RISC_OS_Documentation/index1700.html

You will find example documents produced for different drafts and some conversions here: https://github.com/gerph/riscos-prminxml-staging (and the produced documentation here: https://github.com/gerph/riscos-prminxml-staging/releases/tag/v2023-03-18)

You will find tools for producing such documents here: https://github.com/gerph/riscos-prminxml-tool

Conversion has already been performed on the bulk of the original PRMs, and whilst there’s more work to do, it’s ‘merely’ a matter of adding the updates. No small task, but having documentation in the same format, in a good looking and managed form, and which can be updated by anyone without cost, is a goal that everyone should get behind… for the reasons you just said.

Is it possible for an icon (with an outline font) to have multi-coloured text?

No. If you look at the icon definition, there is a single place for the text colour. (Actually two, but they are alternatives depending on several of the flag settings – you can’t use both at the same time.)

To achieve that you’d either have to have multiple icons (and with proportionally spaced fonts positioning them so the text looked right would be messy), or put the text in a sprite.