A quick question to Chris Johnson about !Snapper. Can it be made to snap
the entirety of a window that is partially off the current screen?

For example, I used Martin Würthner's !DiscSpace to examine a directory's
use of space, and its output is a rather long window only part of which is
on screen at any moment. I wanted to snap the whole window in one go, but
I don't think Snapper can do it. Is that just inevitable?

--
Bernard

In article <8b5792b759.boase@bernard>,
<b.boase@bcs.org> wrote:
> A quick question to Chris Johnson about !Snapper. Can it be made to
> snap the entirety of a window that is partially off the current
> screen?

> For example, I used Martin Würthner's !DiscSpace to examine a
> directory's use of space, and its output is a rather long window
> only part of which is on screen at any moment. I wanted to snap
> the whole window in one go, but I don't think Snapper can do it.
> Is that just inevitable?

I am afraid it is. It uses a sprite op to grab the specified part of
the visible screen. If part of the window is off screen, then it
cannot be grabbed (the wimp will not be redrawing the offscreen part
anyway).

It is something that has been discussed in the distant past (user
postings and David and myself). It originally was raised as a way to
grab complete web pages (longer than the screen) in one go. What
would be required would be seriously hacky.

Possibilities:
1) Ask the task to redraw its whole window in to a buffer which could
then be copied or obtained by Snapper. Requires the task to be fully
cooperative - have its own code, and in any case Snapper would be
superfluous if the task could do it itself.

2) Automate the manual long way. If the window was on-screen but not
full size, Snapper could (in some currently unknown way) snap the
visible part, force a scroll of the window by passing open_window
messages to the task, and snap again, repeating until there were
grabs for the whole window, Then the individual parts would need to
be stitched together.

3) Do something similar to 2, but using one of the virtual screen
apps and forcing the virtual screens to change. Stitching still
required.

In the words of the old country gentleman, when asked for directions
to wherever, he thought it would be better to start somewhere
completely different (ie not Snapper).

If anyone has any bright ideas, let us know.

--
Chris Johnson

In article <59b79a56e8chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:

[Snip]

> In the words of the old country gentleman, when asked for directions
> to wherever, he thought it would be better to start somewhere
> completely different (ie not Snapper).

> If anyone has any bright ideas, let us know.

If you go Windows side and use Snagit, you have two larger than screen
grab options, scrolling to grab a page longer than a screen full, like a
webpage, or even a Panoramic option.

Dave

--

Dave Triffid

In message <59b79a56e8chrisjohnson@spamcop.net>
on 8 Feb 2022 News wrote:

> In article <8b5792b759.boase@bernard>,
> <b.boase@bcs.org> wrote:
> > A quick question to Chris Johnson about !Snapper. Can it be made to
> > snap the entirety of a window that is partially off the current
> > screen?

[snip]

> 2) Automate the manual long way. If the window was on-screen but not full
> size, Snapper could (in some currently unknown way) snap the visible part,
> force a scroll of the window by passing open_window messages to the task,
> and snap again, repeating until there were grabs for the whole window, Then
> the individual parts would need to be stitched together.

This should be possible, as the work area extent scroll offset and other
details required can be read even if you don't own the window. Indeed,
Snapper must be reading some of this information already. Then, as you say,
open window requests could be sent to scroll the window (which would also
mean Snapper would have to poll the Wimp to allow the redraw to take place).

If would be hard to make it work for a task which polls during its redrawing
because it has to get the content together and wants to be responsive, but
for simpler apps it would be possible.

Quite fiddly to code, and stitching the sprites together would be a bit of
work. Would be a pain if there were two dimensions to scroll in!

--
Matthew Phillips
Durham

On 8 Feb 2022, b.boase@bcs.org wrote:

> I don't think Snapper can do it. Is that just inevitable?

Okay, chaps, understood. In the event I used Snapper on two parts of the
window in question and did my own stitching in PhotoDesk to give an
effective, if rudimentary, single sprite result. Probably too rare a case
to bother with a difficult automatic solution, but thanks for indulging
me!

--
Bernard

In article <3c11beb759.Matthew@sinenomine.co.uk>,
Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> This should be possible, as the work area extent scroll offset and
> other details required can be read even if you don't own the
> window. Indeed, Snapper must be reading some of this information
> already. Then, as you say, open window requests could be sent to
> scroll the window (which would also mean Snapper would have to poll
> the Wimp to allow the redraw to take place).

Snapper certainly has to get the state of the window in question to
do its thing. During a snap it already polls quite a bit and sends
window open messages to do things like bring target window to top,
and then put it back again, and to fill the snap area when grabbing a
menu for example. To set scroll bar positions is therefore possible.
One thing of course is that the full extent of a window is not likely
to be an exact multiple of the visible area, so some snaps would be
for only part of the window content.

When I have nothing better to occupy me, I might have a play to see
what is possible. The stitching might be the larger task in the end.

--
Chris Johnson

In article <59b7c5bb69chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:

> I might have a play to see what is possible

This may indeed be a very silly idea, but as most modern monitors are
effectively widescreen, and all tend to be landscape, is there any mileage
in rotating the sprite area 90 degrees for the snap, and then returning it
to normal aspect, or doing this same thing on a "banked" screen out of the
user's vision.

Obviously won't address all cases, but might cover a significant number.

And then there's the (probably equally silly) idea of a virtual long
portrait screen to plot to and read from. It could be mimicked scaled-down
on the screen itself.

As I say, probably all very silly, but may spark a less silly idea in
someone who knows what they're talking about!

John