Calling redraw() on a widget means to set all damage() bits in the
widget's status. If you do this inside draw() of the widget these
damage() bits will be cleared after draw() which means that you can't
effectively call redraw() inside draw(). You *may* call it on other
widgets but you should not assume any drawing order to avoid undefined
behavior.
I was actually indeed calling it on another widget. I tricked myself out by adding a timeout that would call redraw().
> I attach my modified version of ScrollB which provides the behavior I
> think you want. I moved the invocation of move_to() outside the
> Scroll_B::draw()
> method, into a callback function for ScrollB's vertical scrollbar.
Excellent! Without checking the code in detail or testing it myself (I
only read your code quickly), this is generally how it should be done.
Thanks for investigating and helping!
Great! works fine, many thanks. I was looking for a way to intercept the scrolling of the Fl_Scroll and only thought of the draw() function. It is of course much better to provide my own version of the callback() of the scrollbar.
On a further note, I was also trying to get my own scrollbars into an Fl_Scroll widget, but that looks like it cannot be done?
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
