Mouse clicks during window resize

I’d assume the idea is to make sure that the area of the sprite which was originally visible will remain visible at the new scale. So if you start with the full sprite visible, then the user drags the adjust size icon up and right to create a short and wide window, the view would zoom out because that’s the only way it can keep the full sprite visible.

It’s the only way it can keep the full sprite visible respecting that window height, with the down side that there’d be an empty black border to the right hand side. On the other hand I feel like I have seen draggable rectangles on UIs with locked aspect ratio. That’s do-able if the code looks at which dimension, x or y, has the biggest change from when the user started dragging, and then scales based on that, adjusting the other dimension of the window to maintain the aspect ratio. I feel like that would make the “drag to zoom” be a bit more like the “wheel to zoom” where the window always stays the same shape as you zoom in and out. Your way works though and addresses my earlier concern. I’ll give it some thought.

So you might have to make the work area really big (effectively infinite), and have “virtual” scroll bars instead of real ones. (There’s probably some way of doing this by nesting/layering windows ontop of each other)

Given my current rate of progress on this bounty Jeffrey that feature sounds like a perfect candidate for version 2.0 (or would that be 3.0?) :-)

One difficulty you might run into – regardless of the approach you’re using to track drag start/end – is that the Wimp will try and limit the drag to the extents of the window’s work area.

What do you mean by “the window’s work area”? When I try and do a regular window resize, RISC OS limits my mouse movement to the edge of the screen, even though I have “Allow windows off-screen” configured. This happens regardless of the sprite size.

Ah, now I see what you mean – if the sprite is smaller than the screen I can’t drag the window out at all when it’s fully expanded (and if you make a tiny sprite, Paint won’t let you shrink the window either, so you can’t resize at all!). That’s a right pain!

Well if RISC OS won’t allow a resize off the edge of the screen I suppose the client area doesn’t need to be infinite – it just needs to be a bit bigger than the screen. However, does this mean we’d swap in different scroll bars (or an expanded client area) only when the user attempts a Ctrl+Resize? Or do we make the sprite window huge right from the start even for the very smallest sprite just for this feature?

What do you mean by “the window’s work area”?

For each dimension, there are four key window properties:

• The work area minimum size
• The work area maximum size
• The visible area size
• The scroll offset

The Wimp constrains the values so that (a) they’re all greater than or equal to zero, (b) the work area maximum size must be greater than or equal to the work area minimum size, and (c) the work area maximum size must be greater than or equal to the visible area size plus the scroll offset (n.b. I think that for the Y axis some/all of the values are negative, so take this with a pinch of salt). The size of the bar in the scroll bar indicates the ratio between the work area maximum size and the visible area size.

If you can already see all of the sprite (i.e. work area maximum size == visible area size) then by default the Wimp won’t let you drag the window out to make it any bigger, so you won’t be able to drag the window out to zoom in. However it looks like there’s already a solution to this problem via bits 14 and 15 of the window flags, which causes the work area maximum size to be ignored when dragging. So you should be able to ignore most of what I was talking about there!

However it looks like there’s already a solution to this problem via bits 14 and 15 of the window flags, which causes the work area maximum size to be ignored when dragging. So you should be able to ignore most of what I was talking about there!

Great news! Thanks Jeffrey!

I think that for the Y axis some/all of the values are negative, so take this with a pinch of salt

Yes, the vertical axis normally has zero at the top and the bottom being minus-something.
This is normal, but not mandatory.

I got fed up of the calculations for Manga (window resizes to fit image, and scroll wheel moves up and down and can cope with only partial view), so I just set the bottom to be zero and the top to be plus-something. Works fine, and the scrolly maths is simpler too. ;-)