Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1056 > unrolled thread

Nested window question

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Nested window question Rik Griffin <nospam@denbridgemarine.com> - 2011-11-22 13:11 +0000
    Re: Nested window question Martin Wuerthner <spamtrap@mw-software.com> - 2011-11-22 16:51 +0100
      Re: Nested window question Rik Griffin <rik.griffin@btinternet.com> - 2011-11-23 13:54 +0000
      Re: Nested window question Gerph <gerph@gerph.org> - 2011-11-24 13:55 -0800
        Re: Nested window question Rik Griffin <nospam@denbridgemarine.com> - 2011-11-25 09:50 +0000

#1056 — Nested window question

Imagine an application with a window, within which is nested another
window. Lets call the parent window 'A' and the nested child 'B'.

I want A's scroll bar[s] to scroll window B, without scrolling window A.
They'd both have to have the same extent in the relevant direction, but
that's easy enough to arrange.

Is this possible, and if so can someone give me a clue how to go about it?

Thanks very much :)

-- 
Rik Griffin
Standard disclaimer, not speaking for anyone but myself, blah blah
(Reply-To may be broken: use rik dot griffin at denbridge marine dot com)

[toc] | [next] | [standalone]

#1057

In message <6fb1233652.rik-news@iyonix.elements>
          Rik Griffin <nospam@denbridgemarine.com> wrote:

> Imagine an application with a window, within which is nested another
> window. Lets call the parent window 'A' and the nested child 'B'.

> I want A's scroll bar[s] to scroll window B, without scrolling window A.
> They'd both have to have the same extent in the relevant direction, but
> that's easy enough to arrange.

> Is this possible, and if so can someone give me a clue how to go about it?

You can do that by creating A without a scroll bar and adding another 
nested window C that is just a scroll bar located at the position 
where A's scroll bar would normally be. Then, when you get open (or 
scroll) requests for C, you open both C and B at the given scroll 
position.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1059

In message <b866323652.martin@bach.planiverse.com>
          Martin Wuerthner <spamtrap@mw-software.com> wrote:

> You can do that by creating A without a scroll bar and adding another 
> nested window C that is just a scroll bar located at the position  where
> A's scroll bar would normally be. Then, when you get open (or  scroll)
> requests for C, you open both C and B at the given scroll  position.

Excellent, that works nicely, thanks very much.

-- 
Rik Griffin

[toc] | [prev] | [next] | [standalone]

#1060

On Nov 22, 3:51 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> In message <6fb1233652.rik-n...@iyonix.elements>
>           Rik Griffin <nos...@denbridgemarine.com> wrote:
>
> > Imagine an application with a window, within which is nested another
> > window. Lets call the parent window 'A' and the nested child 'B'.
> > I want A's scroll bar[s] to scroll window B, without scrolling window A.
> > They'd both have to have the same extent in the relevant direction, but
> > that's easy enough to arrange.
> > Is this possible, and if so can someone give me a clue how to go about it?
>
> You can do that by creating A without a scroll bar and adding another
> nested window C that is just a scroll bar located at the position
> where A's scroll bar would normally be. Then, when you get open (or
> scroll) requests for C, you open both C and B at the given scroll
> position.

Precisely what I was going to say, with the exception that this will
not handle
scroll requests caused by alternate pointing devices (eg scroll
wheels). In order
to support them (IIRC), you need to set the 'extended scroll requests'
flag on
window B and handle the Poll Reason ScrollRequest for the scrolls for
window B and updating window C to reflect them. Depending on the
usage, you may already be handling such requests for line/column
scrolling. You may also consider that scroll requests are needed for
Window A if there are regions of window A that are visible whose
scrolling by the scrollwheel should affect window B.

Additionally, you should be using Wimp_Extend 11 in order to locate
the correct size of the furniture in order to place window C correctly
- which might actually need to affect the size of window A if you have
a hard requirement on the size of the workspace for window A. I don't
remember whether the furniture locations were exposed by the modern
versions of the Window manager but I have a bad feeling that they were
not - for scrollbars it may be 'safe' to assume the the vertical
scrollbar is on the right, and the horizontal on the bottom as other
combinations are a bit odd.


However... depending on your intended use you can implement this in a
different manner.
If window B is to comprise most of window A (or window B is just one
of multiple windows which comprise window A, such as a vertically/
horizontally split view), it is common to want to use the top of the
window as a toolbar (and maybe another on the left and/or bottom). In
such cases you might consider the following scenario:

Window A is the primary window which is entirely obscured by child
windows - but has scrollbars.
Window B which covers most of the workspace of window A.
Window C which is the toolbar for Window A.

  +------------------------------------+
  |  window A title bar              |x|
  +------------------------------------+
  |  toolbar window C                  |
  +----------------------------------+-+
  |                                  |^|
  | scrollable window B              |||
  |                                  |v|
  +----------------------------------+-+

The right handle scrollbar is the scrollbar for window A.
window B could be only half the workspace, and a window D added, eg:

  +------------------------------------+
  |  window A title bar              |x|
  +------------------------------------+
  |  toolbar window C                  |
  +---------------+------------------+-+
  |               |                  |^|
  | scrollable    | also scrollable  |||
  | window B      | window D         |v|
  +---------------+------------------+-+

To do this, toolbar window C is created as a furniture window which
spans the entire extent of Window A (use Wimp_GetWindowOutline, IIRC).
Another, similar window could be added to the bottom which was a
status bar or additional toolbar. Horizontal scrolling can be done in
the same way.

window B is nested, attaching its vertical scroll to the parent window
(as is window D), which ensures that when window A is scrolled, window
B scrolls with it. In order
to ensure that toolbar C is never completely obscured, the minimum
extent of window A should never be smaller than the minimum height of
window B or D + minimum height of window D (or width for horizontal
scroll.

For the split B/D form you need to move the left of window D yourself,
and the right of window B yourself. For the B version alone, you
merely attach the extents to the edges of the window when nesting,
which ensures that as A changes size, B changes with it.

The advantage of this solution is that you need do less work yourself
(excepting, of course, the split window), as scrolling window A
implicitly scrolls windows B/D, and the extent of the scrollbar
correctly represents the scroll extent of window B. The extent of
window A needs to include the height of toolbar C, but you'd have to
take this into account in any almost any solution (there is another,
below, which does not).

Similarly, because window B/D have no scrollbars they receive no
scroll requests from alternative scroll devices (scrollwheels) - and
because they don't, the parent window is instead considered. The
parent is window A, which does have a scrollbar so is allowed to
scroll - and as I mentioned above, scrolling window A implicitly
scrolls windows B and D, so there is no extra work for this either.


The further alternative solution I referenced above is a slightly more
complex arrangement which removes the need to account for the height
of toolbar C.

  +------------------------------------+
  |  window A title bar              |x|
  +------------------------------------+
  |  toolbar window C                  |
  +----------------------------------+-+
  |                                  |^|
  | scrollable window B              |||<- Window E
  |                                  |v|
  +----------------------------------+-+

This looks identical to the first diagram, but the differences is that
window A has NO scrollbars. Window C just covers the horizontal
workspace of window A (no need for outline). Window E is nested in
window A and has a scrollbar - its extent *exactly* matches that of
window B, which is then nested within Window E.

If you split window B (into the B/D solution as mentioned above)
there's no real difference in the behaviour compared to the above
solution. The main thing is that the scrollbar is now only taking
account of the extent of window B and not the dead space used by the
toolbar window C. Particularly for windows whose extents are small,
this may make a visual difference to the scrollbar's extent.



Your description doesn't necessarily imply any of the above scenarios-
which only really apply to the case where you are covering most of the
visible area of window A.
If you were to be doing something like this:

  +------------------------------------+
  |  window A title bar              |x|
  +----------------------------------+-+
  |                                  |^|
  |    +---------------------+       |||
  |    | scrollable window B |       |||
  |    +---------------------+       |||
  |                                  |v|
  +----------------------------------+-+

Then that's ... a bit weird, but there's nothing to stop you - and the
way that Martin suggested (with my caveats about scroll requests)
would be the way to go.

I would, generally, suggest not going against the expectations of the
user - scrolling a region which is not obviously related to the
scrollbar can be a little jarring on the user's experience, in much
the same way that if you clicked an option icon and the text toggled
red instead of changing the option icon would be jarring. But you know
that :-)

Usual caveats about my memory apply.

--
Gerph

[toc] | [prev] | [next] | [standalone]

#1061

In message <d0d70569-6629-4e75-a770-9750106f457d@p9g2000vbb.googlegroups.com>
          Gerph <gerph@gerph.org> wrote:

> lots of interesting stuff

Thanks for all that info, I shall digest it at length.

For the record, the layout I'm trying to achieve is this:

  +------------------------------------+
  |  window A title bar              |x|
  +----------------------------------+-+
  |                                  |^|
  |                                  ||| scroll bar (window C)
  |  window B                        |||
  |                                  |V|
  |                                  +-+
  |                                  |ƒ| window A's resize icon
  +----------------------------------+-+

Whereby window A can be resized (hence resizing the nested window B), and
the scroll bar scrolls B, which to the user simply looks as though it is
A's work area. The twist is that B is a toolbox gadget that's implemented
as a nested window, eg a text area.

It's relatively straightforward even with the gadget in there, as long as
the gadget supports the Gadget_MoveGadget method, and also some way of
obtaining the actual ObjectId of its window object (eg
TextArea_GetWindowId).

On an OpenWindow request for A, set the gadget's BBox to cover A's work
area.

Then, window C's extent (ie the scrollbar) is set to match that of the
gadget's window.

On an OpenWindow request for C, update the gadget's window's scroll offset
as well.

Now to implement ScrollRequests! Thanks again for the info.

-- 
Rik Griffin
Standard disclaimer, not speaking for anyone but myself, blah blah
(Reply-To may be broken: use rik dot griffin at denbridge marine dot com)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web