Re: Nested Wimp

In message <c616baf34d.root@xxxxxxxxxxxxxxxx>
Erik Groenhuis <erikgspm@xxxxxxxxxxxx> wrote:

As Alan Adams <alan.adams@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

I am trying to create a spread***-like effect, with a row of column
headers, fixed at the top of the window, and a long scrolling area below it.

Sounds like a similar thing to what I am working on (in C). As soon as I
have mine working propperly, I hope to make it into an open source
library, or set of sources to compile and link with a programmer's own,
or maybe even into a Toolbox Object.

At the moment the headers are a separate window without furniture on top of
the main window. One bit of fiddling I had to do was to adjust the
scrolling, because part of the scrolling area is hidden by the headers, so a
page down operation scrolled too far.

The trick for this is to add a margin at the top of the work area of
the main window. Make that margin the same height as the pane(s) at the
top.

If your document normally looks like:

+--------------------
| First line
| Second line
| Third line
| ...

then make it now look like:

+--------------------
|
|
|
| First line
| Second line
| Third line
| ...

This will ensure that:

- When the window is full size, all of the document's contents is
visible and the verticall scroll bar fills it's entire well.

- When the scroll bar is at the top, the first line of you document is
displayed just below the header pane (as it should be).

- When the scroll bar is at the bottom, the last line of your document
is displayed at the bottom of the window.

What this *doesn't* fix (and I now suspect that this was the problem
you were describing) is when you click in the well of the scroll bar
('page scroll'). You'd expect the document to jump one visible page at
the time. The actual jump has the size of the whole window.

For that I think you should catch Scroll Requests from Wimp_Poll, look
for y scroll direction (at offset 36 in the block) -2 or 2 (page
down/page up) to set the desired amount of scrolling.

(This is now on my own TODO list, as I hadn't noticed this problem yet.)


That's exactly the problem, and the solution I am using at the moment.

For 1 or -1 I use the height of one row of data. For 2 and -2 I use the
*current* height of the main window - the height of the pane.

You also need to deal with X scrolls - for which I use the width of one
column. fortunately you don't seem to need to worry about the end conditions
- moving the scroll too far is correctly handled so the bar goes to the end.
(Unlike Edit, which seems to get confused at the bottom of large windows.)

Where I have some unresolved issued is with getting the windows to behave
ALWAYS as though they were a single window. At the moment, open-windows
calls are working, so the pane always is opened on top, and at the correct
position. To do that I have had to read the main window parameters, read the
pane, change the pane position to one based on the main window, then open it
as the top window (behind -1). Then I open the main window behind the pane.

As a result, the back button doesn't work, because the open always brings
them to the top. However bringing other windows to the top does work.

If I don't force the pane to the top, it tends to become invisible - I
suspect it is behind the main window, and positioned accurately so as to be
completely hidden.

It is this sort of thing that I hope the nested wimp will do for me.
However, as you saw from yesterday's post, I do have some problems getting
to grips with the logic for that.

Incidentally the main windows has, with the test data, 89 rows of 9 icons,
and can reach almost 2000 icons. That is why scrolling was noticed early on.

--
Alan Adams, from Northamptonshire
alan.adams@xxxxxxxxxxxxxxxxxxxxxxxxxxx
http://www.nckc.org.uk/
.