Wimp behaviour when resizing windows

This sounds like a bug in WindowManager to me, but I’m going to assume its something apps are doing wrong when creating windows.

If you drag the left part of a resizable window off-screen and then drag to resize it, WindowManager moves the left side back onto the screen. Is there a flag to stop it doing this?

My interpretation of the window flags is that WindowManager should only do this if bit 13 is set?

It makes resizing a window that doesn’t fit fully on-screen impossible.

@ Jon

This sounds like a bug in WindowManager to me, …

I can confirm that it most likely it’s a bug in the WindowManager, or at least a weird behavior.

In my Launchpad I expressly:

- set flag 6 to 1
- set flag 13 to 0
- set flag 21 to 0

But yes, moving Launchpad window a bit off screen on the left and then try to resize it will still trigger the behavior as if flag 21 and/or 13 were set to 1, which it should not as far as I understand.

It isn’t just the left side of the screen.

The same effect is seen on all four edges of the screen.

It makes resizing a window that doesn’t fit fully on-screen impossible.

I do not see that problem. (5.28 on a Pi 4)

Clicking the bottom right of a window that has its title bar off screen is the only way to get it back on screen. So it is a useful bug.

I do not see that problem. (5.28 on a Pi 4)

Open a Window, make it the width of your desktop resolution, drag it off the left side of the screen and then try to make the Window wider than the screen width…you can’t because the left of the Window springs back on screen, meaning you can only ever manually resize a Window to the desktop resolution…which is a bit annoying if you’re running at a low resolution.

Clicking the bottom right of a window that has its title bar off screen is the only way to get it back on screen. So it is a useful bug.

There is that, but there’s a Window flag to prevent that occurring. Once opened you can’t drag a window off-screen to the point you can’t get at the title bar to move it.

What I can’t work out is how it tells the difference between a Window that’s been moved off screen – which is allowed, and a Window that’s being resized off-screen – which isn’t allowed. Even if you fix the Window position offscreen when the WimpPoll returns with the open window request, it still springs back onscreen when resizing.

OK, there’s a load of stuff here.

Jon said

If you drag the left part of a resizable window off-screen and then drag to resize it, WindowManager moves the left side back onto the screen. Is there a flag to stop it doing this?

Yes there is: Window Flags bit 6 “No bounds”.

Paolo thought

it’s a bug in the WindowManager, or at least a weird behavior

It’s not a bug, though there’s a degree of historical artefact about it, as we’ll see.

Jon continued

Open a Window, make it the width of your desktop resolution, drag it off the left side of the screen and then try to make the Window wider than the screen width

This is a different thing, and is much more interesting.

Originally b6 did something much more restrictive – windows were kept completely on screen unless b6 was set. This was relaxed in RO3 so that you could move any window to the side temporarily, which meant that the bit that used to keep the window on screen no longer kept the window on screen. However, it was believed that if you were resizing the window then obviously you’d want it all on screen or why are you resizing it? This isn’t a bug, it’s a GUI design decision.

Because some windows really did have to be kept on screen, bit 13 was introduced to mean “No really, keep this window on screen”. So b13 did what b6=0 used to do in RO2 and Arthur… but only when b6=0. If b6=1 (“no bounds”) then the window can go off screen regardless of b13.

When b6 “No bounds” is set, then not only can the window be dragged partially off the left of the screen, it can then be resized off the left of the screen too, losing it completely. I regard this as a bug, and there’s an opportunity to enforce b13 “Stay on screen” here to refer to the pointer, meaning the window would resize but keep its edge on screen.

However, if the extent of the window is larger than the screen size, moving the window off the side of the screen does not allow the pointer to size the window larger than the screen. Again, that’s intended, but not necessarily helpful.

Note that windows certainly can be larger than the screen – this restriction only applies to DragType 2 – resize window. Setting the size of a window manually via Wimp_OpenWindow (which anyone can do regardless of ownership these days) allows a window to be made any size… but amusingly if a window is already larger than the screen, and is off the left so that the resize icon is accessible, then attempting to resize it with the pointer will apply the screen-size constraint and drag the pointer off the left of the screen. Again, deliberate but unhelpful.

There are various work-arounds including nesting your own ‘resize’ icon in the corner, and resizing the parent window accordingly as that pane is dragged. Another is to keep a record of where your window was and pay attention to the window flags and parameters of the OpenWindow request during a resize and simply override the Wimp’s suggested coordinates. But none of these things can be applied universally.

The current behaviour is partly an artefact of the RO3 finessing, and partly conflict between flexibility and the danger of losing a window off screen – I hardly need point out that the whole purpose of scrollbars is to enable a larger-than-screensize area to be accessed… trying to do the same by dragging a larger-than-screensize window off the side of the screen is somewhat contrarian.

However, there’s another point here, and one I’ve long regarded as a deficiency (though it is much less important now) – large dialogs on small screens. This is usually catastrophic for various reasons, and as it’s a different subject with different solutions, I’ll start another thread for that.

The current behaviour is partly an artefact of the RO3 finessing, and partly conflict between flexibility and the danger of losing a window off screen

If lost it should come back on if you change to a mode with a different (lower?) resolution.

Not if b6 “No bounds” is set – once it’s offscreen it stays offscreen.

Probably why some applications constantly force their floating tool panes back on screen, even if the window they are associated with has been moved off screen by !Workspace

Hot-key capture windows need to stay offscreen, so there’s an interesting heuristic to be spun there.

Note that windows certainly can be larger than the screen – this restriction only applies to DragType 2 – resize window. Setting the size of a window manually via Wimp_OpenWindow (which anyone can do regardless of ownership these days) allows a window to be made any size

That was the first workaround I attempted. Before performing the Wimp_OpenWindow, I reset the left coordinate in the Poll block back to the window’s previously negative value. That appeared to end up with a Window that’s left coordinate was negative when read back, but visually on-screen was 0.

I need to attempt a Repro, to see if it wasn’t an issue with my code or the version of Window Manager I was using at the time.

There used to be a race condition in the Wimp that resulted in all multitasking stopping unless (and until) your task opened a window exactly where the Wimp asked it to (including Z-order). That was fixed decades ago. So it is always possible to respond to an OpenWindow request by opening the window somewhere else.

Also note that if you set b6 to enable the window to be resized off-screen and then toggle it off again, the window will get pulled back onto the screen. Grrr.

note that if you set b6 to enable the window to be resized off-screen and then toggle it off again, the window will get pulled back onto the screen

That comment, combined with messing with a Repro led me a workaround:

1. Create and open the window with b6 unset
2. Get the X,Y bounds via Wimp_GetWindowState
3. Delete the Window
4. Recreate the Window with the X,Y bounds from step 2 and b6 set

That then results in a Window that initially opens on-screen, but can be resized off-screen. A bit convoluted I confess, but works.

So the actual issue is not what I originally thought. The issue is with the behaviour of Wimp_OpenWindow when b6 is unset – it lets you drag the Window off-screen, but the documentation would imply that shouldn’t be possible.

but the documentation

<gets out the usual soapbox and stands on it>

Delete the Window

That’s unnecessary unless you want compatibility with very old Wimps – you can change the window flags using OpenWindow.

So you can “open the window with b6 clear” and then immediately “open it with b6 set”:

!q%=mainW%:SYS"Wimp_GetWindowState",,q%
q%!28=-1:q%!32=q%!32ANDNOT(1<<6):SYS"Wimp_OpenWindow",,q%,&4B534154,-1,1
q%!32=q%!32OR(1<<6):SYS"Wimp_OpenWindow",,q%,&4B534154,-1,1

Note the use of the “nested” API to set the window flags too.

I need to support a stock RISC OS 3 Archimedes, so can’t use any of the later Wimp additions. Admittedly, I have put some code paths in where it makes sense – updating Icons for example, but I don’t think I need bother here as it only happens once when the window is initially created.

RO3

Cool.

so can’t

Quite so.

Small request Nemo – when posting code examples could you spare a thought for us feeble humans and use the SWI names rather than numbers :-)

Apologies. Done.

Leaving the semi-magic string of characters, of course, because everyone knows what that spells backwards.
Wandering curious mind: Why only TASK anyway?

Wandering curious mind: Why only TASK anyway?

Why is “TASK” used?

This was introduced in RISC OS 2 to denote a Wimp “task”, a program that runs in a multitasking manner. If one is to omit the “TASK”, they’ll get a weird sort of singletasking frankenWimp as the thing attempts to offer you the full Arthur experience.

As to why “TASK” is used for all sorts of other changes, well, it’s &4B534154 in a memory word that must exist for Wimp Init, so it’s just as easy to pull it into a register and compare when wanting to do other enhancements, such as selecting the extended version of OpenWindow.

There are a number of APIs which having not been designed with future expansion in mind, had no way of indicating that exciting! new! registers! had been added – such as via a flags word – so a special magic value is used that is theoretically vanishingly unlikely to already be in that register.

You can see why using the same magic value for different SWIs would be a forehead slapper, hopefully.

Then we get to the wonderful example of Wimp_PlotIcon, which was expanded in RO4.3 via, yes, the same TASK magic number but they screwed up the registers resulting in R5 being interpreted both as the Y coordinate and as a flags word. At the same time. So they fixed that by changing to a different magic number… which is “KSAT”. Cos they got the first attempt arse-backwards.

FTR I don’t think it’s a good idea to use the same magic in different SWIs, and I also don’t think it should be all uppercase or lowercase, just in case.

&4B534154 in a memory word that must exist for Wimp Init

(Quirky query¹) True, but why?

¹ I’m in that kind of mood right now – Chris has a thing on the TV (Youtube) showing the “Rush, Freewill” take on musical time signatures.

why?

A value that would be very unlikely to be in that register otherwise.

Except when it’s used all over the place (Nemo speaks truth, they all should have been different if extended this way rather than with foresight).

True, but why?

Because it was a flag to tell the original Wimp that it was a multitasking task. Because, previously, the Wimp Initialise call took nothing on entry (Arthur PRM book 2 p448), the registers could be anything. Because of this, it was deemed necessary to use a specific unique word that wasn’t liable to be there “by accident”.
It’s a shame, as a flags word might have been more useful than all this reliance on passing different version numbers, but retrofitting stuff into existing APIs is fraught, especially given there is no calling standard so registers not documented as having a purpose could contain anything and you can’t corrupt registers not documented as being corrupted.

That this word crops up in other places is, perhaps, laziness rather than anything else. Though I think one of the colour calls uses “WIDE”, perhaps as “TASK” is a bit nonsensical?