On 09/27/12 13:20, Eric Sokolowsky wrote:
> After trying a few more things I found a recipe that seems to work, but it is
> a bit of a kludge. At the end of my class's draw() function (this is the
> class that derives from Fl_Scroll, and has a Fl_Pack as a member) I check to
> see if the window needs to scroll, and if it does, I recursively call the
> draw function just once. I think that the widget's position is not updated
> until sometime in the draw() code so perhaps I need to just find where that
> is done and put my scroll check right after that to see if I can avoid the
> recursive draw() call.
Right -- that might actually be the /right/ thing to do if your code
is running inside draw() code already.
My sugg was for a situation where the redraw() request is being done
/outside/ of a draw() context. (Inside a draw() context, it might cause
a recursion, so you'd have to protect from recursion the same way you
are
already, which I expect involves a static variable and a counter, eg:
static int recurse = 0;
if ( recurse == 0 )
{
recurse = 1;
// ..code to run once goes here..
recurse = 0;
}
As I think you've found, Fl_Scroll's draw() code probably is doing
some calculations that are affecting you, such that the data won't
be valid until /after/ Fl_Scroll's draw() function returns.
You should maybe try to schedule what ever you're doing /outside/
the draw() method of your widget if possible, since draw() code
should really just draw, not change stuff.. especially if you're
a child widget that's changing the parent.
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
