How to scroll exactly to bottom of Fl_Scroll?

[chris]

I have a vertical Fl_Pack inside an Fl_Scroll. Is there an "offical" way
how to programatically scroll exactly to the bottom of the Fl_Pack?

Or do I have to walk the contents of the Fl_Pack in order to determine
its height by summing up all elements heights and then "scroll_to()"
that value minus the Fl_Scroll height?

Is there something easier that I miss?

[Albrecht Schlosser]

First of all: Fl_Pack is ... let's say, somewhat tricky, i.e. it may not
exactly do what you expect or how you expect it to do it. The main
problem with Fl_Pack is that it calculates (and is able to change) its
own size (i.e. w() and h()) in its draw() method, depending on its
children's sizes. It is often easier to use one's own derived class to
do what you need so you have better control.

That said, you may be able to use Fl_Pack's y() and h() to locate the
bottom of the Fl_Pack, and then you'd only have to do some offset
calculations and use scroll_to() as you suggested (I assume: add y() +
h() - Fl_Scroll's y()). The only problem with this technique would be
(AFAICT) that you must make sure that draw() was called at least once
before you do your calculations.

[chris]

Am 05.01.2017 um 13:55 schrieb Albrecht Schlosser:
> On 05.01.2017 13:05 chris wrote:

> First of all: Fl_Pack is ... let's say, somewhat tricky, i.e. it may not
> exactly do what you expect or how you expect it to do it. The main
> problem with Fl_Pack is that it calculates (and is able to change) its
> own size (i.e. w() and h()) in its draw() method, depending on its
> children's sizes. It is often easier to use one's own derived class to
> do what you need so you have better control.
>
> That said, you may be able to use Fl_Pack's y() and h() to locate the
> bottom of the Fl_Pack, and then you'd only have to do some offset
> calculations and use scroll_to() as you suggested (I assume: add y() +
> h() - Fl_Scroll's y()). The only problem with this technique would be
> (AFAICT) that you must make sure that draw() was called at least once
> before you do your calculations.
>

Oh yes, that's the reason it didn't work for me. I read the height of
the pack in the constructor of my widget, after filling up the pack but
before it was drawn, so it still had the size I created it with.

Will try to postpone the scrolling until I am sure it has been drawn.
Not nice, but doable..

Thanks all for the quick replies.

@Ian: You are right, just querying the height should suffice, would
there not be this minor pre-condition ;)

[Duncan Gibson]

Chris wrote:
> Oh yes, that's the reason it didn't work for me. I read the height of
> the pack in the constructor of my widget, after filling up the pack
> but before it was drawn, so it still had the size I created it with.
>
> Will try to postpone the scrolling until I am sure it has been drawn.
> Not nice, but doable..

You could try to add a one-off timer callback in the constructor
to re-calculate the scroll heights once the Pack has been shown
and then call redraw(). Might give an unwelcome screen jump though

D.


This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

[chris]

> You could try to add a one-off timer callback in the constructor
> to re-calculate the scroll heights once the Pack has been shown
> and then call redraw(). Might give an unwelcome screen jump though

That's what I did for now (though a little more refinded: I overloaded
Fl_Pack::draw() to detect, when it is drawn and then fire the timer once).
My initial program was so elegant, now it is nearly doubled in LOC with
this hack :(

P.S. Looks as if there have been plans to extend the functionality of
Fl_Pack. I have found this thread in "FLTK Development":

http://www.fltk.org/newsgroups.php?s1+gfltk.coredev+v14867+T0

Citing from this message:
"+1 on adding right and bottom justification, although I don't think
that bottom justification would be very useful, but who knows..."

==> Guess that would have been exactly what I need here..

[Albrecht Schlosser]

On 05.01.2017 18:06 chris wrote:

> ... Looks as if there have been plans to extend the functionality of

> Fl_Pack. I have found this thread in "FLTK Development":
>
> http://www.fltk.org/newsgroups.php?s1+gfltk.coredev+v14867+T0
>
> Citing from this message:
> "+1 on adding right and bottom justification, although I don't think
> that bottom justification would be very useful, but who knows..."
>
> ==> Guess that would have been exactly what I need here..

I don't think so. This patch wouldn't change the behavior that Fl_Pack
resizes itself in its draw() method.

Note: I remember that I looked into the code and found out that it's
necessary for consistent behavior in all FLTK widgets to allow widgets
to resize themselves in their draw() methods. Given that children of
Fl_Pack *can* resize themselves in their draw() methods Fl_Pack must do
the same *after* drawing the children - IIRC. Or something like that.

It's not trivial to understand or change this, particularly not without
some risk to break existing programs. :-(

See STR #3092 for more info and a link to the thread mentioned above in
fltk.coredev (@ Google Groups):

http://www.fltk.org/str.php?L3092

https://groups.google.com/d/msg/fltkcoredev/hY9hVG5v-4s/47SHMiBdq4cJ