1. Forum
  2. Usenet
  3. COMP.SYS.ACORN.APPS

  • Snapper

    From [email protected]@21:1/5 to All on Tue Feb 8 14:25:05 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From News@21:1/5 to [email protected] on Tue Feb 8 15:52:26 2022
    In article <8b5792b759.boase@bernard>,
    <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave@21:1/5 to News on Tue Feb 8 19:11:49 2022
    In article <[email protected]>,
    News <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthew Phillips@21:1/5 to All on Tue Feb 8 22:22:41 2022
    In message <[email protected]>
    on 8 Feb 2022 News wrote:

    In article <8b5792b759.boase@bernard>,
    <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [email protected]@21:1/5 to [email protected] on Tue Feb 8 23:11:25 2022
    On 8 Feb 2022, [email protected] 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From News@21:1/5 to Matthew Phillips on Tue Feb 8 23:46:24 2022
    In article <[email protected]>,
    Matthew Phillips <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Williams (News)@21:1/5 to News on Wed Feb 9 08:47:56 2022
    In article <[email protected]>,
    News <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)