|
|
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?
Many thanks for all the help. Geert
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/23540b68-a81b-4ac1-a725-4a54f797c390n%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |